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1.  TECHNICAL  PROBLEM 


7 1  "T 


The  Scientific  Data  Department  (SD)  of  the  Defense  Mapping  Agency 
Hydrographic/Topographic  Center  (DMAHTC)  is  responsible  for  the  acquisition, 
evaluation,  maintenance  and  exploitation  of  data  related  to  the  disciplines 
of  bathymetry  and  hydrography.  As  the  accelerated  exploitation  of  the 
world's  oceans  continues  due  to  increased  demands  for  accurate  sea  floor 
topography  in  support  of  both  national  defense  and  natural  resource 
exploitation,  DMAHTC' s  role  was  becoming  more  difficult  due  primarily  to: 


/  An  increase  in  the  amount  of  data  arriving  at  DMAHTC  for  inclusion 
into  its  library  system; 

/  A  dramatic  increase  in  the  number  of  requests  for  data  by  users, 
both  old  and  new;  and 

/  The  ever-increasing  demands  for  more  accurate  data  being  provided 
in  a  more  timely  manner. 

Recognizing  the  situation,  DMAHTC/SD  embarked  on  the  phased  development 
of  a  system  that  would,  as  a  minimum,  be  capable  of:  converting  analog 
sources  into  digital  data;  storing  the  data  in  a  bathymetric  data  base; 
evaluating  and  manipulating  the  stored  data;  and  outputting  the  data  in  a 
form  acceptable  to  DMAHTC  customers.  This  system,  known  today  as  the 
Bathymetric  Data  Reduction  Subsystem  (BDRS) ,  was  to  be  part  of  a  DMAHTC-wide 
system  capable  of  supporting  its  goals  and  objectives  digitally. 


2.  GENERAL  METHODOLOGY 


Methods  used  during  the  course  of  the  36-month  project  included  in-depth 
analysis  of:  production/operational  environments;  existing  DMAHTC  hardware 
systems;  and  hardware/software  technologies.  The  independent  digitization, 
batch  and  data  base  subsystems  were  developed  independently  according  to 
specific  user  requirements.  Interactive  software  dialogues  and  procedures 
were  based  on  user  inputs.  System  test  and  evaluation  was  performed  at 
DMAHTC,  Washington,  D.C. 
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3.  TECHNICAL  RESULTS 


The  BDRS  system  concluded  that:  the  concept  was  valid;  efficient 
conversion,  storage  and  maintenance  of  digital  bathymetry  exists;  operational 
procedures  were  key  to  the  integration  of  the  three  subsystems;  and  the 
selected  hardware  was  responsive  in  meeting  the  goals  and  objectives  of  the 
development  effort.  The  major  technical  result  was  the  accurate  and  timely 
conversion,  storage  and  retrieval  of  digital  bathymetry /hydrography  in 
support  of  DMAHTC  operational  goals  and  objectives. 


4.  IMPLICATIONS  FOR  FURTHER  RESEARCH 


Three  major  areas  should  be  addressed  as  future  considerations: 

Hardware  technology;  Digital  Data  Base  exploitation;  and  Interfaces  to 
existing,  planned,  and  future  DMAHTC  systems.  Regarding  hardware  technology, 
input  devices  and  automated  techniques,  capable  of  cost-effectively 
converting  source  material  to  a  usable  digital  format,  are  continually 
being  developed  and  tested  in  the  laboratories.  The  inclusion  of  such 
devices  and/or  techniques  into  the  existing  BDRS  framework  would  greatly 
enhance  the  system's  ability  to  support  the  growing  production  demands 
being  placed  on  DMAHTC.  Additionally,  computer/peripheral,  communications 
and  plotter /recorder  hardware  should  be  continually  monitored.  The  area 
of  digital  data  exploitation  should  be  seriously  considered  for  further 
research.  Expansion  of  existing  data  base  capabilities  in  support  of 
additional  on-line  data  base  users  and  the  development  of,  and  experimen¬ 
tation  with  additional  data  manipulation  and  exploitation  techniques  capable 
of  providing  new  and  varied  products  to  DMAHTC  customers,  should  be 
rigorously  pursued.  Interfaces  to/from  DMAHTC  systems  should  be  carefully 
designed  and  reviewed  to  insure  data  interchangeability/compatibility 
between  systems  supporting  the  same  goals  and  objectives. 


5.  SPECIAL  COMMENTS 


The  BDRS  is  one  of  the  first  major  multi-technology  systems  imple¬ 
mented  in  the  production  environment  for  the  purpose  of  supporting  bathy¬ 
metric/hydrographic  production  requirements. 


S-ii 


TABLE  OF  CONTENTS 


1.  INTRODUCTION  .  . 

1 . 1  Purpose  .  . 

1.2  Organization 


1-1 

1-1 

1-1 


2 .  MATHEMATICAL  APPLICATIONS 


2-1 


2.1  Purpose  . 2-1 

2.2  Registration . 2-1 

2.2.1  Problem  To  Be  Solved . 2-1 

2.2.2  Method  of  Solution . 2-1 

2.2.3  Source  and  History  of  Approach . 2-5 

2.2.4  Empirical  Results  and  Evaluation  .  2-6 

2.2.5  Future  Topics  of  Interest  .  2-6 

2.3  Coordinate  Transformations  .  2-6 

2.3.1  Problem  to  be  Solved . 2-6 

2.3.2  Method  of  Solution . 2-7 

2. 3. 2.1  Mercator  Mapping  Equation . 2-7 

2. 3. 2. 2  Inverse  Mercator  Mapping  Equation . 2-8 

2. 3. 2. 3  Transverse  Mercator  Mapping  Equation  .  2-10 

2. 3. 2. 4  Inverse  Transverse  Mercator  Equations  .  2-11 

2. 3.2. 5  Additional  Projection  Transformations  .  2-13 

2.3.3  Source  and  History  of  Approach . 2-13 

2.3.4  Empirical  Results  and  Evaluation  .  2-13 

2.4  Geographic  Sectioning  Algorithms  .  2-13 

2.4.1  Problem  to  be  Solved . 2-13 

2.4.2  Method  of  Solution . 2-14 

2. 4. 2.1  Circle  Search  .  2-14 

2. 4. 2. 2  Polygon  Search  .  2-15 

2. 4. 2. 3  Path  Search  . 2-20 

2.4.3  Source  and  History  of  Approach . 2-20 

2.4.4  Empirical  Results  and  Evaluation  .  2-20 

2.5  Fathogram  Processing . 2-21 

2.5.1  Problem  to  be  Solved . 2-21 

2.5.2  Method  of  Solution . 2-21 

2.5.3  Source  and  History  of  Approach . 2-33 

2.5.4  Empirical  Results  and  Evaluations  .  2-33 


3.  SOFTWARE  ACCOMPLISHMENTS 


3-1 


3.1  Purpose  . 

3.2  Digitization  and  Voice  Entry  Subsystem 

3.2.1  Data  Entry  . 

3.2.2  Fathograms  . 

3.2.3  Registration  . 

3.2.4  Review  Mode  . 

3.3  Batch  Processes  Subsystem  . 

3.3.1  Fathogram  Processing  . 

3.3.2  Plot  Functions  ....  . 


3-1 

3-1 

3-1 

3-2 

3-2 

3-2 

3-2 

3-2 

3-3 


TABLE  OF  CONTENTS  (Continued) 


3.3.3  Depth  Adjustment  .  2-6 

3.4  Data  Base  Subsystem  .  3-8 

3.4.1  Data  Flow .  3-8 

3.4.2  Mapping  .  3-14 

3.4.3  Sectioning .  3-16 

THE  PROBLEMS  OF  ACCURACY .  4-1 

4.1  Purpose .  4-1 

4.2  Data .  4-1 

4.2.1  Accuracy  of  Source  Analog  Data .  4-1 

4. 2. 1.1  Charts  .  4-1 

4 . 2 . 1 . 2  Fathograms .  4-2 

4.2.1. 3  Data  Entry  of  Analog  Source  Materials  .  4-2 

4.2.2  Accuracy  of  Processed  Data .  4-3 

4. 2. 2.1  Registration  .  4-3 

4. 2. 2. 2  Coordinate  Transformations .  4-3 

4. 2. 2. 3  Fathogram  Processing  .  4-4 

4.3  Problem  of  Validation .  4-5 

SYSTEM  CONFIGURATION  .  5-1 

5.1  Purpose .  5-1 

5.2  Hardware  Configuration  .  5-1 

5.3  BDRS  Software  Configuration  .  5-4 

5.3.1  Software  Description . ,  5-4 

5. 3.1.1  Key  Areas  .  5-4 

5.3.2  Digitizing  Software  .  5-12 

5.3.3  Batch  Software .  5-14 

5.3.4  Data  Base  Software .  5-14 

5. 3.4.1  On-Line  Data  Base .  5-14 

5. 2. 4. 2  Batch  Data  Base  .  5-19 

5. 3.4.3  Data  Base  Master  Mode .  5-19 

5.3.5  Files  and  Record  Formats .  5-19 

5.3.6  Data  Base  Structure .  5-21 

CONCLUSIONS  AND  RECOMMENDATIONS  .  6-1 

6.1  General . . 

6.2  Hardware . . 6-2 

6.3  Software . 

6.3.1  Operating  System  (RDOS)  .  6-7 

6.3.2  Applications  Software  .  6-8 

6.4  File  Maintenance . 6-15 

APPENDIX  A  -  GLOSSARY . . 

APPENDIX  B  -  BDRS  Functional  Software  Loadlines  .  B-l 

APPENDIX  C  -  BDRS  Files  and  Record  Formats . C-l 


ii 


tk 


m 


¥**.  ' 


LIST  OF  FIGURES 


2-1  Spherical  Geometry  Overview  .  2-22 

2-2  North  Pole  Triangulation  Illustration  .  2-23 

2-3  South  Pole  Triangulation  Techniques  .  2-25 

2-4  North  &  South  Poles  Triangulation  Illustration  .  2-26 

2-5  Ship's  Track  Line . 2-28 

2-6  Example  of  a  Speed  Change  Segment  of  Track  .  2-31 

2-7  Adjusted  Track  of  Ship . 2-32 

2- 8  Example  of  a  Course  Change  Segment  of  Track  .  2-34 

3- 1  Adjusted  Course  Display  .  3-4 

3-2  Track  Line  Output  from  Fathogram  Processing  .  3-5 

3-3  Depth  Adjustment  Grid  Matrix . 3-7 

3-4  Data  Flow  Through  the  BDRS  . 3-10 

3-5  Example  of  the  Mapping  Grid  Scheme . 3-11 

3-6  Possible  Situations  .  3-13 

3-7  The  Mapping  Grid . 3-15 

3-8  Mapping  a  Circle  Path  or  Polygon . 3-17 

3-9  The  Mapping  Function . 3-18 

3-10  International  Dateline  Problem  .  3-19 

3-11  Examples  of  Bounding  Rectangles  .  3-21 


3-12  Example  of  a  Single  Test  Point  Within  an  Area  of  Interest  .  3-23 

3-13  Example  of  a  Bounding  Rectangle  W/Test  Points  Outside  the  .  3-24 

Area  of  Interest 

3-14  Problem  of  Bounding  Rectangles  Large  than  Area  of  Interst  .  3-25 
3-15  Circle  Search  Problems  .  3-26 


3-16 


Crossing  0  Degrees  of  Longitude 

ill 


3-28 


LIST  OF  FIGURES  (Continued) 


5-1  BDRS  Hardware  Configuration  . 

5-2  Station  1  . 

5-3  Station  2  . 

5-4  Examples  of  the  BDRS  Systems  Utilization  of  Foreground  .  . 

Background  Processing 

5-5  Single-Task  Program  . 

5-6  Multitask  Program  . 

5-7  Task  Control  Block  and  Use  of  Re-entrant  Code  . 

5-8  Overlays  . 

5-9  Digitization  Functional  Architecture  . 

5-10  Digitization  Input  and  Output  . 

5-11  Batch  Input/Output  . 

5-12  File  Map  . 

5- 13  BDRS  Data  Base  Structure  . 

6- 1  BDRS  Hardware  Configuration  . 

6-2  Enhanced  BDRS  Configuration  . 

6-3  International  Dateline  Plots  . 

6-4  Cross  Sectional  Display  . 

6-5  Botton  Contour  Display  . 

6-6  Profile  Display  . 


iv 


EVALUATION 


The  Bathymetric  Data  Reduction  System  resulting  from  this  development 
effort  is  installed  and  operating  within  the  Scientific  Data  Department  of 
the  Defense  Mapping  Agency  Hydrographic  Topographic  Center  (DMAHTC) .  This 
is  the  first  system  of  its  kind  capable  of  the  evaluation  of  fathograms, 
digityzing  of  Bathymetric  source  data,  processing  the  data  into  a  uniform 
geographic  reference  frame  and  the  inclusion  of  the  digital  data  into  the 
digital  Bathymetric  Data  Library.  The  system  provides  for  the  efficient 
provision  of  digital  data  to  the  variety  of  nautical  chart  products  pro¬ 
duced  by  DMAHTC  and  will  prove  of  great  value  in  the  cost  effective, 
accurate  production  of  DOD  required  products.  This  effort  is  within 
Technical  Plan  thrust  R2D. 


Project  Engineer 


v 


SECTION  1.  INTRODUCTION 


1.1  PURPOSE 


The  purpose  of  this  document  is  to  first  present  an  account  of  the 
critical  subsystem  and  technical  problems  encountered  during  the  design, 
development,  and  implementation  of  the  BDRS.  Secondly,  to  provide  an 
evaluation  of  the  solutions  developed  by  Synectics  Corporation  to  these 
problems. 


1.2  ORGANIZATION 


This  document  is  divided  into  five  areas.  Section  2  is  dedicated  to 
a  discussion  of  problems  whose  solutions  are  mathematical  in  nature.  A 
discussion  of  the  software  accomplishments  pertaining  to  the  BDRS  is  given 
in  Section  3.  Section  4  deals  primarily  with  problems  of  accuracy  that 
occur  in  data  input  and  manipulation.  Section  5  identifies  and  discusses 
the  hardware  and  software  configurations  utilized  to  meet  the  functional 
objectives  of  the  BDRS.  The  last  section  will  deal  with  conclusions  and 
recommendations  relative  to  the  current  and  possibly  future  BDRS.  Addition 
ally,  three  appendices  are  provided  with:  Appendix  A  containing  a  "BDRS 
Glossary  of  Terms";  Appendix  B  detailing  the  load  lines  for  all  BDRS 
functional  software;  and  Appendix  C  identifying  and  discussing,  in  detail, 
all  BDRS  file  and  record  formats. 
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SECTION  2.  MATHEMATICAL  APPLICATIONS 


2.1  PURPOSE 


The  purpose  of  this  section  is  to  provide  a  detailed  account  of  the 
mathematical  algorithms  and  their  applications  within  the  BDRS  problem  en¬ 
vironment.  The  four  contexts  in  which  algorithms  have  been  developed  are 
registration,  coordinate  transformations,  geographic  sectioning  and  fatho- 
gram  processing. 


2.2  REGISTRATION 


2.2.1  Problem  To  Be  Solved 

The  problem  to  be  solved  by  n  point  registration  is  twofold.  First, 
a  function  must  be  constructed  whose  domain  is  comprised  of  physical  X-Y 
locations  on  a  digitizing  table  and  whose  range  is  comprised  of  X-Y  coordi¬ 
nates  in  an  earth  rectangular  frame,  given  that  n  values  (3  to  8)  of  the 
function  are  known.  The  construction  of  this  function  is  referred  to  as 
day  '1'  n-point  registration.  Second,  a  function  must  be  constructed  which 
maps  table  X-Y  locations  to  table  X-Y  locations  given  that  n  (from  3  to  8) 
values  of  the  function  are  known.  This  construction  is  entitled  day  'n' 
n  point  registration. 

Day  *1'  registration,  from  an  empirical  point  of  view,  results  in  the 
geodetic  significance  of  points  on  a  map  which  has  been  placed  on  the  digit¬ 
izing  table.  Day  'n'  registration  results  in  mapping  back  to  day  1  the 
points  on  the  map  as  it  lies  on  the  table  translated  or  rotated  relative 
to  the  day  1  registration  of  the  map.  Since  both  algorithms  are  identical 
from  a  mathematical  point  of  view,  it  suffices  to  give  a  presentation  of 
day  1  registration. 


2.2.2  Method  of  Solution 

The  idea  of  the  n-point  registration  is  to  convert  X-Y  table  values  to 
a  form  which  can  be  converted  to  lat/long  values  on  the  earth's  surface.  A 
pure  table  X-Y  value  is  physically  meaningless. 

The  problem  is  a  typical  statistical  one  of  finding  a  function  given 
that  you  know  some  of  the  ordered  pairs  that  the  function  must  satisfy. 

In  registration  you  know: 


(a)  the  table  X-Y  values  of  the  registration  points 

(b)  the  map  scale  mil  values  of  the  lat/long  values  of  the  registration 

points  (the  map  scale  mil  values  are  found  by  taking  the  output 
from  the  map  projection  itself  and  converting  to  units  of  mils) 

To  be  more  precise,  let  X1,  x2,...Xn  be  the  map  scale  mil  X  values  of  the 

registration  points,  let  Y1,  Y2,...Yn  be  the  map  scale  mil  Y  values  of  the 

registration  points,  let  X.,  X_,...X  be  the  known  table  X  values,  let 

12  n 

Y,  ,...Y  be  the  table  Y  values.  You  know  for  each  ordered  pair  of  X-Y  table 
in  . 

points  X^,Y^  the  map  scale  mil  equivalent  X1,Yi.  This  constitutes  the 
known  relations  which  must  be  approximated  by  the  function  being  sought.  What 
properties  should  the  function  have  beside  fitting  the  known  data?  Simplicity 
requires  that  the  function  be  linear.  Geometrical  considerations  suggest 
finding  two  function  f,g  such  that 

(a)  f  (X.  , Y . )  -  X1 

1  1 

(b)  gfX^Yj  -  Y1 

Given  the  assumption  of  linearity  we  get 

(a)  f (X . , Y . )  =  AX.+BY.+C  =  X1 

li  11 

(b)  g(X.,Y.)  =  DX  +EY.+F  =  Y1 

ii  i  l 

Now  we  must  impose  some  conditions  which  allow  us  both  to  solve  for  A,B,C,D,E 
and  F  unambiguously  and  which  lend  geodetic  meaning  to  the  physical  table 
X-Y  values.  That  is,  given  an  arbitrary  table  X-Y  pair,  the  functions  f  and 
g  must  map  the  pair  into  an  approximately  correct  map  scale  mil  ordered  pair. 

The  classical  approach  to  a  statistical  problem  in  a  linear  model  is  the 
least  squares  best  fit  algorithm.  The  idea  is  to  minimize  the  sum  of  the 
squares  of  the  differences  between  known  data  values  and  the  values  predicted 
statistically.  In  registration  we  have  known  map  scale  mil  values.  We  want 
the  functions  f  and  g  to  yield  predicted  map  scale  mil  values  such  that  we 
minimize  the  sums  of  the  squares  of  the  differences  between  the  predicted 
map  scale  mil  values  (i.e.,  f (X  ,Y  )  ,  gtX^Yj  and  the  known  map  scale  mil 
values  (i.e.,  X^Y1). 

More  explicitly,  given  that 

(a)  X1  =  AX.+BY.+C 

i  l 

(b)  Y1  =  DX.+EY.+F 

1  1 
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minimise 


(c)  .  E 
x=  1 

IX 
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(d)  E 

IY 

i-1 

by  picking  the  correct  values  of  A,B,C,D,E,  and  P 


Lot  HIxSx.  ,Y.)  =  E  [X1-(AX.+BV.+C))i 


i  l 


i-  1 


and  G  (Y1 ,  X.  ,Y . )  =  E  [Y1- <AX. +BY . +C) ) 2 
1  1  i=l  11 

the  requirement  of  minimizing  these  expressions  is  logically  equivalent  to 
the  following  six  equations: 


— 

—  '* 


(1) 

;>h 

3A 

(2) 

M 

(3) 

,)H 

JC 

(4) 

3G 

3d 

(5) 

3g 

3e 

(6) 

3G 

3f 

Taking  the  derivatives  and  simplifying  we  get  the  following  six 
equations:  „  n  «  n 


(1)  A  E  (X.)2  +  BE  X.Y.  +  CE  X.  *  E  xV 
i-1  1  i=l  1  1  i=l  1  i-1  1 

n  n  ?  n  n  i 

A  E  X.Y.  +  B  E  (Y . )  +  C  E  Y  =  E  X  Y 
i=l  1  1  i-1  1  i-1  1  i-1  1 


(2) 


n  »»  j 

(3)  A  E  X.  +  B  E  Y.  +  n  *  E  X 

i-1 


i=l 

n 


n 

E 

i-1  1 

n 


(4)  D  E  (X  )‘  +  E  E  X.Y.  +  F  Z  X  -  E  yV 
i-1  x  i-1  1  1  i-1  i=l 
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n 

D  E 

XV.  +  E  I 
ii  .  , 

(Y.)2 

i 

+  F  [ 

i=l 

1=1 

i=l 

n 

a 

n 

D  E 

x.  +  e  >: 

Y  + 

n  =  E 

i=l 

1  i=i 

l 

i=l 

Note  that  all  expressions  are  known  in  the  above  equations  except  for 
A,B,C,D,E,  and  F.  To  solve  for  these,  treat  equations  1,2,  and  3  as 
3  equations  in  3  unknowns  A,B,  and  C;  and  treat  equations  4,5,  and  6 
as  3  equations  in  3  unknowns  D,E,  and  F.  Then  we  can  write  equations 
1-3  and  4-6  as: 

XY  =  Z 
XW  =  V 


where 


n 

n 

n 

E 

(X.) 

E 

X.Y. 

E 

i=l 

i 

i=l 

1  X 

i=l 

n 

n 

2 

n 

E 

X.Y. 

E 

(Y. )  ^ 
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i=l 

l  1 

i=l 

x 
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E 
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n  \ 

E  xxx. 
i=l  1 


"  x\ 
i=l  1 


V  ./  E  A? 

/  i-1  1 


n 

I  YXY 


Note  that  X  is  a  symmetric  matrix 


I 


To  solve  for  Y  = 


the  inverse  of  X;  X  to  get 


(1)  /  A 


(2)  /  D  = 


The  matrix  X  exists  if  its  determinant  is  non-zero  which  seems  to  work 
always.  If  it  does  not  work,  new  registration  points  must  be  chosen. 

The  software  for  this  approach  requires  solving  for  the  elements  of 
X, Z, W,  finding  X  \  and  multiplying  X  *Z  and  X  *V.  Having  found  these 
values  we  have  for  an  arbitrary  table  XY  pair  X^Y^  that 

(1)  X1  =  AXj+BYj+C 

(2)  Y1  =  DXi+EYi+F 

Upon  conversion  of  X^Y1  to  meters  we  multiply  by  the  map  scale  to  get 
U1,V1;  the  earth  scale  meter  equivalents  of  X^Y1.  This  pair  U'Sv1  is  the 
input  into  the  inverse  map  projection.  The  output  is  the  pair  6,ip  called 
the  latitude  and  longitude  of  the  table  point  X^,Y_^. 

2.2.3  Source  and  History  of  Approach 


The  adopted  approach  to  registration  was  developed  'in-house'  at 
Synectics  Corporation.  In  particular,  the  idea  of  solving  for  the  X  and  Y 
dimensions  independently  resulted  in  minimizing  errors  which  could  result 
from  redigitizing  single  control  points  when  a  registration  is  unacceptable. 


i . 
!: 
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Since  the  mathematical  model  of  registration  is  both  statistical 
and  linear,  there  are  empirical  situations  in  which  problems  can  arise. 

In  the  ideal  situation,  the  source  map  is  not  distorted  badly  by  shrinkage 
or  expansion.  We  have  noted  that  such  distortion  is  rarely  compensated 
for  within  the  linear  model.  A  distorted  map  can  be  registered  within 
the  residual  tolerance  level.  This  should  not  be  taken  as  evidence  that 
the  statistical  fit  has  adequately  compensated  for  the  distortion.  The 
model  is  linear;  therefore,  the  scaling  which  occurs  is  uniform  along  an 
axis.  Thus,  the  actual  map  shrinkage  is  spread  uniformly  over  the  map. 

This  could  make  the  functions  constructed  in  registration  both  meet  the 
residual  test  and  fail  to  provide  an  adequate  mapping.  Thus,  the  chart 
must  be  known  to  be  in  good  condition  or  poor  empirical  data  from  the 
table  might  be  allowed  to  infiltrate  the  data  base. 

It  is  crucial  to  pick  registration  points  intelligently.  If  8 
registration  points  are  picked  representative  of  the  map  as  a  whole,  that 
is,  in  no  obvious  geometrical  pattern,  and  the  document  is  in  good  physical 
condition,  then  the  results  of  registration  can  be  trusted.  All  mathe¬ 
matical  computations  are  performed  in  over-kill  double  precision. 


2.2.5  Future  Topics  of  Interest 

Since  the  mathematical  model  of  registration  is  linear,  the  idea 
obviously  arises  of  utilizing  a  model  in  which  non-linear  terms  contribute 
to  statistical  prediction.  The  linear  model  is  quite  satisfactory 
given  a  chart  in  good  condition  and  an  intelligent  choice  of 

registration  points.  Thus  the  employment  of  a  non-linear  model  would  be 
motivated  if  an  attempt  were  made  to  register  charts  in  less  than  optimal 
condition. 

The  linear  model  could  also  be  supplemented  with  a  normally  distri¬ 
buted  error  term  whose  expectation  value  is  zero  and  whose  standard 
deviation  reflects  user  input  in  accuracy  in  entering  a  control  point. 
However,  it  seems  arbitrary  to  assign  such  a  standard  deviation  for  an 
arbitrary  user.  Thus,  this  term  does  not  appear  in  the  functions  con¬ 
structed  by  registration. 


2.3  COORDINATE  TRANSFORMATIONS 

2.3.1  Problem  to  be  Solved 


The  problem  to  be  solved  by  the  coordinate  transformations  is  to 
convert  between  earth  rectangular  and  geodetic  coordinates  utilizing 


the  Mercator,  Miller,  Lambert,  Polyconic  and  Transverse  Mercator  proiections. 
The  conversion  from  geodetic  to  earth  rectangular  coordinates  is  effected  by 
the  map  projection  itself.  Inverses  had  to  be  constructed  as  well  to  con¬ 
vert  earth  rectangular  to  geodetic  coordinates. 


2.3.2  Method  of  Solution 


The  projection  types  utilized  are  conformal  projections.  As  Thomas 
has  shown  in  "Conformal  Projections  in  Geodesy  and  Cartography",  Coast  and 
Geodetic  Survey  Special  Publication  251,  all  conformal  mappings  of  the 
spheroid  upon  a  plane  are  expressed  by  the  analytic  function 


X+iy  =  f(A+ir) 
r  =  In  [tan 


(5 , 

4  2 


where 

)  . 


1-gsinq) 

±+£sin(J> 


S/2 


and  cf>  equals  the  latitude  of  the  point,  A  the  longitude  and  K  the  eccen¬ 
tricity.  The  form  of  the  Mercator  and  Transverse  Mercator  mapping  is  then 
determined  by  which  line  or  lines  in  the  projection  are  to  be  held  true  to 
scale  and  by  the  necessary  geometric  form  of  map  elements  corresponding  to 
meridians  and  parallels.  Once  the  form  of  f  is  determined,  the  real  and 
imaginary  parts  of  X+iy  =  f(A+ir)  are  equated  which  must  in  turn  satisfy  the 
well  known  Cauchy  Riemann  equations: 


(1)  3x  =  3y 
3X  3r 

(2)  3x  =  -  3y 
3r  3A 

to  finally  obtain  x  as  a  function  of  A  and  r  and  y  as  a  function  of  A  and  r. 
The  mapping  equation  is  thus  derived. 


2. 3. 2.1  Mercator  Mapping  Equation 

The  Mercator  projection  is  the  simplest  and  most  basic  of  the  conformal 
map  projections.  The  form  of  f  is  linear  and  the  initial  conditions  quite 
simple.  As  Thomas  indicates,  the  initial  condition  is  that  the  scale  of  the 
projection  must  be  true  at  the  equator.  Thus,  for  a  latitude  of  <{>=0,  r=ln(l) 
=  <\>,  and  Y=0;  and  x=aA,  the  product  of  the  equatorial  radius  and  the  longi¬ 
tude  A.  Thus  since  x+iy=f(A+ir)  we  have  aA+i.4>=f  (A+i.<t>)=f  (A)=a  (A+ir)  .=x+iy. 
Equating  real  and  imaginary  parts  of  x+iy=a.  (A+ir)  we  have: 
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(1) 

(2) 


x=aX 

y=ar=  a. In 
=  a.lnl 


tan  (tt  +  I  4?  | ) 
4  2 


(sin4>+l ) 
cos<p 


C/2 

l+£sin<(>^  _J 

C/2 


/  l~Csin(p ' 

*  T  / 

I  l~Csin<j)  \  ^ 

'  i  , r_ ^  I 


l+£sin<t>' 


The  scale  or  magnification  of  a  point  at  latitude  4>  given  a  conformal  pro¬ 
jection  is  the  Jacobian  of  x  and  y  with  respect  to  r  and  X  divided  by  Ncos<|) 

where  N=  _  a _  ;  the  distance  fro  a  the  point  along  that  line  from  the 

1-t,  sin  <p 

minor  axis  of  the  spheroid  perpendicular  to  the  line  tangent  to  the  point. 

In  this  case  the  scale  become  a  .  sec<J). 

N 

2. 3. 2. 2  Inverse  Mercator  Mapping  Equation 

Given  the  Mercator  mapping  function  Y  =  f (x)  which  maps  a  latitude  to 
an  earth  scale  meter  value,  find  a  method  to  calculate  the  latitude  given 
the  earth  scale  meter  value. 

The  Mercator  mapping  equation  in  question  takes  the  form: 

Y  =  (a/scalac}  * 

Where  Y  =  the  earth  scale  meter  value  and  P  =  the  latitude  value. 

Given  this  form  for  f (x) ,  an  expression  6 (x)  must  be  derived  such  that  the 
form  p  =  6(P)  is  obtained.  Given  an  initial  approximation  P3  to  P,  Wegstein 
iteration  is  used  to  improve  the  desired  latitude  value. 

To  derive  the  form  P  -  6(p)  we  proceed  as  follows.  Since  SCALAC  is  a 
constant  we  eliminate  it  to  get 


tan  (it  +  |P| ) 

.  /1-ZECC.SIN 

(p)  ZECC/2 

4  2 

'1+ZECC. SIN 

(P)/ 

Y.  -  A. In  tan  +  |P |) 

L  4  2 


/ 1-ZECC.SIN (P) \ 
\  J.+ZECC  .  SIN  (P)  / 


ZECC/2 


t, 

_ 


A. In  |  tan  (t^  +  IP  I) 
4  2 


where  Y(P)  =  A. In  /l-ZECC.SIN(P) \ 
'  1+ZECC . SIN (P)' 


+  Y  (P) 
ZECC/2 


But  Y (P)  =  A.ZECC.1/2  In  / 1-ZECC .SIN (P)\ 

'1+ZECC .SIN (P)/ 
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So  if  we  let  B  =  ZECC.SIN(P)  and  use  the  series  expansion  1/2  In  1+B  = 

1-B 

B+1/3B3  +  1/5B5  +...  with  AE2  =  A.ZECC,  AE4  =  A.ZECC.ZECC/3, 

AE6  =  A.ZECC.ZECC.ZECC/5,  we  get 

Y (P) =  SIN (P) . (AE2  +  SIN2(P).(AE4  +  SIN2  P) .AE6) 

Therefore : 


Y  =  A. In 


EXP 


(tan  7T  +  IP)]  -  Y  (P) 
4  2  / 

Y(P)  =  In  ^tan  tt  +  IP  I ^ 
j  Y1  ~  Y(P’[-  tan 


U 


P  *  2  . ^arctan 


( exp  ,  Y  -  Y  (P)  .  )  -  TT 

v  L-S — J  /  4, 


Thus  we  have  derived  the  correct  form  P  =  6(P)  for  use  by  the  iteration  scheme. 

The  initial  approximation  P„  to  P  is  obtained  by  considering  ZECC  =  0; 
that  is,  a  spherical  earth  model  is  employed.  Proceeding  as  before  we  have: 

Y.  = 


i  ■  A-in  (“*■ 

„  =  2.  ^arctan  ^  exp(Yj/A^  -  — ^ 


arctan  exp(Y_ 

^  \  1 

Thus  P„  is  calculated  exactly. 

Having  obtained  P0  and  P  =  6(P)  Wegstein  iteration  is  used  as 
follows: 

(1)  Initialization 
P  =  P 

*  a  1  n 


Px  =  G(P0) 
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P1  =  G^)  +  G  (Pj^)  -  Px 

P  -  P 
1 


GtP^  -P 


-  1 


(2) 


(3) 


At  Iteration  n  +  1 
Pn+1  -  G (Pn) 

Pn+1  =  G  (Pn+1)  +  G  (Pn+1)  -  Pn+1 

Pn+1  -  Pn 
G  (Pn+1)  -  Pn+1 

Convergence  at  tolerance  E 


Pn+1  -  Pn 


Pn+1 


<  £ 


This  will  occur  unless  G  (P)  equals  1  at  P.  Tf  convergence  does  not  occur, 
the  initial  approximation  Pc  is  output  as  the  latitude. 

2.3.Z.3  Transverse  Mercator  Mapping  Equation 

As  Thomas  points  out,  the  initial  condition  of  the  Transverse  Mercator 
projection  is  that  the  scale  is  true  along  the  central  meridian  of  the  map. 
Thus,  for  a  point  at  longitude  zero^and  latitude  <)>  we  have  x=0.  Given  that 
x+iY»f(A+ir)  we  have  iy=f(ir)=i.  -^Rd({)=iS<(>=  the  distance  along  the  meridian 


from  the  equator  at  longitude  A  to  the  point  at  latitude  <(>  with  R=  the  x'  ,ius 
of  curvature  =(1-?2)  .a.  (l-52sin2<{>)  3//2.  But  r  =  C  &  sec<J>d<|>  by  the  condition 

o'  " 

on  r  for  all  conformal  projections.  Thus  dr=R  sec<J>d<{>  and  Rd<J>*Ncos<f>dr. 

y  n 

Therefore  S<p=  /  Ncos4>dr=f  (r)  since  A  is  zero.  Thus  we  have  x+iy»S<))*f  (r)  . 

Now  we  want  to  subject  x  and  y  to  the  Cauchy  Riemann  equations  so  that 
equations  for  x  and  y  in  terms  of  A  and  r  are  needed.  Thomas  proceeds  to 
expand  x+iy=f(A+ir)  about  the  point  z=ir  in  a  Taylor  Series.  Then  real  and 
imaginary  components  are  equated  yielding  the  desired  forms  for  x  and  y  in 
terms  of  A  and  r.  Once  all  terms  are  computed  and  the  Cauchy  Riemann 
equations  applied,  Thomas  reaches  his  desired  mapping  equations. 
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The  scale  K  for  the  projection  at  a  point  A,<J>  is 


Ncos4> 


2  1/2 

1  Ax  .  (1  +  tan  r) 
Ncos<J>  3A 


2. 3. 2. 4  Inverse  Transverse  Mercator  Equations 

The  following  algorithm,  taken  from  Rapp  and  Sprinsky,  Page  30  is 
employed. 


AA  =  sec<p 

X 

-T 

3 

) 

(1  +  2tl2  +  r^2)  +  x 

(if 

N  " 

6  \  N 

I 

12  0 

l  N  1 

4  2  2  2  1 

+24t1  +  6n1  +  8tx  n1  ) 

<h  <t>'  _ 1  <1  +n  2)/x]2  + _ 1  (1  +n  2)  (5  +  3t  2  +  n  2  -4n  4 

2  [ftj  2  4 

+  9n  2t  2)/x\^  tl  (61  +  90t  2  +  45t  4  +  107n  2 
W  720 

-  162e'2  sin2!})'  +  45e,2t^2sin'  4>' )  1 Xj^ 


2.  ,..,2 


-  162e'2  sin2!})'  +  45e  ' 2t^2sin'  4>' )  /  X\^ 


where:  t^  =  tan  <i>' 

n  2-  o'  2 


H1  =  e*  cos  4>' 


e'  =  second  eccentricity  squared 


<J>'  =  foot  point  latitude 
X  =  UTM  Easting 

2  2  I 

N  =  a*/(l  -e  sinz<J))2 
a'  =  .9996. a 

a  =  semi-major  axis  of  the  ellipsoid 

AA  =  longitude  difference  from  central  meridian  of  point. 


<f>  -  latitude  of  point 


e2  -  eccentricity  squared 

Having  computed  AX,  and  <j>,  the  longitude  itself  must  be  computed  as 
follows : 

X  =  -(AX  -  (6(30  -  n)  -  3)  p  ) 
where:  X  =  longitude 

p  =  .01745327252 
n  =  zone  number 

The  first  negative  converts  longitude  positive  eastward  to  positive 
westward. 

A  first  approximation  to  foot  point  latitude  is  computed  from: 

<|>'=S(1  +  S2  (AA  +  S2  (BB  +  S2  (CC  +  S2DD) )  ) ) 

where : 

AA  =  -3e2/6 

BB  =  (12e2  +  45e4)/120 

CC  =  - (48e2  +  1023e4  +1170e6)/5040 

DD  =  (192e2  +  18384e4  +75099e6  +6048e8) /362880 

S  =  Y/ (. 9996a (1-e2)) 

Y  -  UTM  Northing 

Improved  approximations  of  <+> '  are  obtained  by  Newton  iteration,  that 
is: 

•  -  d)'  -  — 

<f>  (i  +  1)'  v  (1)  F' 

where:  F  =  S  -  S  2 


and: 


and: 


S  2  =  A <J>*  -  (B/2)  sin  (24>*)  +  (C/4)  sin  (44)') 
-  (D/6)  sin  (64)') 


A 


+ 


175  6 
256 


B 


+  15 
16* 


+ 


525  6 

5lT 


+ 


105 

256 


e 


D  = 


6 


F'  =  (1  -  e2  sin24>' )  — 

2 


2. 3. 2.5  Additional  Projection  Transformations 

During  the  final  phase  of  the  BDRS ,  three  projection  transformation 
algorithms  were  added.  Those  added  were  Miller,  Lambert,  and  Polyconic. 
A  detailed  explanation  of  each  algorithm  can  be  found  in  the  program 
documentation. 


2.3.3  Source  and  History  of  Approach 

The  Thomas  derived  projections  have  been  rigorously  tested  and  approved 
in  many  cartographic  projects.  The  inverse  to  the  Mercator  Mapping  was 
developed  at  Synectics  Corporation.  The  inverse  to  the  Transverse  Mercator 
mapping  has  been  obtained  from  Rapp  and  Sprinsky. 


2,3,4  Empirical  Results  and  Evaluation 

The  transformations  from  earth  rectangular  to  geographic  coordinates, 
when  combined  with  the  transformations  derived  in  registration,  are  accurate 
to  within  a  second  of  arc  within  the  well-known  bounds  of  application  of 
the  map  projections  themselves.  They  are  accurate  enough  to  satisfy  any 
requirements  which  stays  within  this  limitation.  The  inverse  Transverse 
Mercator  mapping  is  confined  to  one  zone  at  a  time.  The  inverse  Mercator 
mapping  equation  handles  arbitrary  earth  rectangular  values. 

2.4  GEOGRAPHIC  SECTIONING  ALGORITHMS 
2.4.1  Problem  to  be  Solved 

The  sectioning  algorithms  provide  the  capabilities  to  perform  circle, 
path,  and  polygon  searches  within  areas  generated  on  the  surface  of  the 
earth.  The  earth  is  imagined  to  be  a  sphere  of  unit  radius. 


2.4.2  Method  of  Solution 

To  perform  a  given  search,  the  routine  must  be  called  twice;  the 
first  call  generates  the  appropriate  parameters  to  describe  the  region 
in  question,  and  the  second  call  accesses  points  and  calculates  whether 
they  fall  inside  the  test  region. 


2. 4. 2.1  Circle  Search 


•  First  Call 

On  first  call  the  input  lat-long  values  of  the  center  and  radial 
point  are  converted  to  spherical  coordinates  on  a  unit  sphere. 

►'  Second  Call 

First  the  input  test  point  is  converted  to  spherical  coordinates 
on  a  unit  sphere.  Then  the  great  circle  distances  from  the  center 
point  to  the  radial  point  and  from  the  center  point  to  the  test 
point  are  calculated.  If  the  latter  distance  is  less  than  the 
former,  the  test  point  is  within  the  region  defined  by  the  center 
and  radial  points. 

The  distances  are  calculated  as  follows: 

Let  R  and  S  be  vectors  eminating  from  the  origin  of  the  sphere  to 
the  2  points  in  question.  The  dot  product  of  R  and  S  is  the  cosine  of 
the  angle  between  the  two  vectors.  The  angle  is  the  great  circle  distance 
in  question.  Formally  we  have 


R-S 


XlVVlVZl*2 


but 


X^  =■  sinti^  •  cosi$^ 


Y  ^  =  sin0 ^  •  sini(>^ 


Z =  cos0^ 


*  sint; ^  cos$2 


Y^  =  cos$2 


Z^  =•  cosU^ 
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where  0  is  latitude  and  4>  is  longitude.  Thus  R*S  =  sinG^  sin02  ( cos ($  -<()  ) ) 
+  cosS^  cos02,  letting  W  =  distance  sought  we  have 

sinG^  sii 

Q.E.D. 


W  -  ARCCOS 


3in02  (cos(4>1~<{)2) )  +  cosG^  cos02 


2. 4. 2. 2  Polygon  Search 


/  First  Call 

On  first  call,  the  input  lat-long  values  of  the  polygonal  vertices 
are  converted  to  Cartesian  X-Y-Z  coordinates  on  the  surface  of  a 
unit  sphere  centered  at  the  origin  of  the  coordinate  system. 

/  Second  Call 


On  second  call  the  input  lat-long  values  of  the  test  points  are 
converted  to  Cartesian  X-Y-Z  coordinates  on  the  surface  of  a 
unit  sphere  centered  at  the  origin  of  the  coordinate  system. 


To  calculate  whether  a  given  test  point  lies  within  the  polygonal 

test  region,  the  following  insight  is  utilized.  Suppose  the  n  vertices  of 

the  polygon  have  coordinates  <X. ,Y  ,Z  >,  <X_,Y„,Z  >,  ....  <X  ,Y  ,Z  >  and 

ill  2  2  2  nnn 

the  test  point  has  coordinates  <Xfc,Y  ,Z  >.  Consider  the  planes  defined  by 

the  triangles  whose  vertices  are  {<X1*Y1'Z1>»  <X2'Y2'Z2> ’  <X3'R3,Z3>J  ' 

|<X  ,Y  ,Z  >,  <X,,Y  ,Z>,  <-X.  ,Y.  ,Z  >1  ,  - |<X.  ,Y,,Z  >,  <X  -  ,Y  ,  ,Z  >, 

*-  1  1  1  333  4  4  4  J  L  1  1  1  n-1  n-1  n-1 

Xn '  *n '  Zi  and  the  line  defined  as  that  line  connecting  the  origin  to  the 

coordinates  <X  ,Y  ,Z  >.  Let  W.,W_,  -  W  be  the  points  of  intersection 

t  t  t  ±4  n— z 


between  the  line  and  each  of  the  planes.  Let  be  for  a  9iven  triangle 

and  a  given  plane,  the  angles  described  from  the  point  of  intersection 

to  the  triangular  vertices  <\  i'\-i'Zk-l>'  <Xk'Yk'Zk>!}  * 

If  0^+02+03  — 2tt  then  the  point  of  intersection  lies  within  the  triangular 
region.  If  this  occurs  for  at  least  one  triangle,  the  point  is  obviously 
in  the  polygonal  region. 

The  following  is  a  formal  derivation  for  a  test  point  and  a  given 
triangle.  First  the  equation  of  the  plane  of  the  triangle  is  calculated, 
then  the  point  of  intersection  is. calculated,  then  the  origin  of  the 
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coordinate  system  is  translated  to  this  point  of  intersection,  and  finally 
the  angles  are  calculated  and  summed. 

/  Calculate  equation  of  plane  of  triangle 

The  general  equation  of  a  plane  is  given  by  the  formula  A-X+B-Y+ 

C • Z+D=0.  To  determine  the  planar  equation  given  3  points  <X  ,Y  ,2  >, 
<X2'Y2'Z2>'  <X3'Y3'Z3>  we  have  111 


A  *  Y 

<2.  ,-2  )  - 

2,  (Y.  -Y.)  t 

<Vl  '  Z2Y3) 

1 

1  2  1 

12  3 

U  »  - 

V  w 

-  VVV 

,  ,x2q  -  Vj>] 

c  -  Xj 

(W  " 

Y1(X2_X3)  + 

(x2y3-y2x3) 

D  -  -fyww  -  VXjVW  *  Wj'W] 

cj i veil  that  the  three  points  are  triangular  vertices,  the  above  coefficients 
determine  the  plane  of  the  triangle. 

J  Point  of  Intersection 

Suppose  that  RP(I) ,  1=1, 2, 3  is  the  XYZ  coordinate  of  the  test  point. 
Then  the  equation  of  the  line  in  space  through  the  origin  and  the 
test  point  is 


X  =  _Y_  =  2 

RP(1)  RP  (2)  RP  ( 3) 


Suppose  RP ( 1 )  }  0.  Then  we  proceed  as  follows! 
Y  =  RP(2)  -X 


RP(1) 


2  =  RP  (  3)  .  X 
RP{1) 


A-  Xtb-J  HP  (2)  •  X  |  +  C-  [rP  (  3)  •  X  [  + 
[_RP(1)  J  I  RP(1)  J 

X-  A  t  B- RP (2)  +  C-  RP  (3)1  =  - 

L  RP  ( 1 )  RP(1)J 
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X  = 


-  D _ 

A+B • RP ( 2 )  +  C-  RP ( 3) 

RP  ( 1)  RP  (1) 


Let  E  =  B  •  RP  (2 ) 

RP  (1) 

F  =  C  •  RP  (  3 ) 

RP(1) 

H  =  A+E+F 

then  we  have 

X  =  -D 
H 

Let  RPI(I),  1=1,2, 3  be  the  coordinate  of  the  point  of  intersection. 
Then  we  have 

RPI(l)  =  X  + 

H 


RPI (2)  =  RP (2)  -RPig) 

RP  (1) 

RPI (3)  =  RP (3) -RPI(l) 

RP(1) 

/  Translate  origin  to  point  of  intersection 


Suppose  <Xj  ,Y_.  ,Z_.  >  is  an  arbitrary  point  in  X-Y-z  space.  Then 
SJI(I),  1=1, 2, 3  is  defined  as  follows: 


SJI(l) 
SJI (2) 
SJI (3) 

Then  SJI (I)  is  the 


=  X_.  -RPI  ( 1) 

=  Y .-RPI (2) 

1 

=  Z_.-RPI(3) 
translated  point. 
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Note  the  CB  is  the  array  A  translated  to  a  new  origin  at  RPI.  Thus  each 
column  of  CB  is  a  coordinate.  To  find  Proceed  as  Take 

the  following  vector  dot  products 

(1)  <CB ( I / 1) ,  CB (I , 2} > 

(2)  <CB ( 1, 1)  ,  CB ( 1 , 3 ) > 

(3)  <CB ( 1 i 2 ) ,  CB(I,3)> 
according  to  the  formula 

/  B2  +  B2  +  B2  •  cos  0 
V  *  y  z 

where  A  =  A  A  +  A  A+A  A 

x*i  y *  3  z-k 

B  =  B  A  +  B  A+B  A 
x'x  y’j  z-k 

Given  that  the  following  assignments  are  made 

(1)  RMAG1  =  (CB(1,1)2  +  CB(2,1) 2  +  CB(3,1)2)1/2 

2  2  2  1/2 

(2)  RMAG2  =  (CB(1,2)  +  CB(2,2)  +  CB(3,2)  )  ' 

2  2  2  1/2 

(3)  RMAG3  =  ( CB (1,2)  +  CB(2,3)  +  CB(3,3)  )  ' 

we  have  ^  ^ 

(1)  CB  (1,1)  •  CB  (1,2)  =  RMAG1  •  RMAG2  •  COS02  =  D0T1 

->■ 

(2)  CB (1,1)  •  CB (1,3)  =  RMAG1  •  RMAG3  •  cosOj^  =  DOT2 

->  -*■ 

(3)  CB(I, 2)  •  CB(I,$)  =  RMAG2  •  RMAG3  •  COS03  =  DOT3 

Therefore 

(1)  I02  =  DOTl/ ( RMAG1 *  RMAG2 ) 

(2)  10  =  DOT2/  ( RMAG1 '  RMAG3) 

(3)  10  =  D0T3/ (RMAG2  *  RMAG3) 
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Therefore 


(1)  02  -  ARCCOS ( 10 2) 

(2)  0  -  ARCCOS (I0;L) 

(3)  03  -  ARCCOS(I03) 


2. 4. 2. 3  Path  Search 

/  First  Call 

First  the  3  points  input  which  define  the  path  are  converted  to 
XYZ  coordinates  on  the  surface  of  a  unit  sphere  yielding  <X^'Y^,Z  >, 
<X2,Y2,Z2>,  <X3'Y3«^3>*  The  vertices  of  the  quadrangle  defined  by  the  path 

are  found  as  follows.  Let  Ax=X3~X2,  ^Y=Y3~Y2  and  ^Z=Z3~Z2*  The  four 
vertices  are: 

U)  <x3,y3,z3> 

(2)  <x2-Ax,y2-Ay,  z2-Az> 

(3)  <X1-AxfY1-AY,  Z1-AZ> 

(4)  <x1+Ax,  y^+Ay,  z^+Az> 

This  follows  by  the  obvious  symmetry  of  the  sphere. 

/  Second  Call 

This  is  just  a  4  sided  polygon  search. 
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consists  in  assuming  that  the  earth  is  circular.  Thus  geodetic  paths  on  the 
ellipsoid  are  considered  to  be  great  circle  paths  on  the  surface  of  the  earth. 
For  large  earth  test  areas,  this  could  result  in  some  inaccuracy  in  polygon 
searches.  The  extent  of  the  inaccuracy  has  not  been  rigorously  analyzed. 


2.5  FATHOGRAM  PROCESSING 

2.5.1  Problem  to  be  Solved 


The  major  problem  to  be  solved  in  fathogram  processing  is  how  to  mathe¬ 
matically  solve  for  a  latitude,  longitude  position  along  the  ship’s  track 
at  a  regular  interval.  To  obtain  a  solution  to  this  problem 
the  following  questions  must  be  answered.  Should  calculations  take  into 
consideration  the  curved  surface  of  the  earth  or  deal  only  with  a  plane  as 
if  the  ship's  track  was  plotted  on  a  chart?  What  navigational  data  (geo¬ 
graphic  positions,  courses,  speeds)  should  be  assumed  to  be  the  most 
accurate?  If  adjustments  to  the  navigational  data  is  necessary,  how  should 
they  be  made? 


2.5.2  Method  of  Solution 


To  deal  with  the  ship's  track  as  if  it  were  on  a  flat  surface  such  as 
a  chart  seems  questionable  since  the  ship  does,  in  reality,  travel  over  a 
curved  surface.  Therefore,  the  approach  utilized  to  solve  this  problem 
considers  the  track  as  it  actually  occurs  along  the  curved  surface  of  the 
earth.  All  of  the  mathematical  computations  deal  not  with  a  plane,  but 
with  a  curved  surface.  Basically  this  involves  the  use  of  Great  Circle 
Sailing  Computation  which  is  nothing  more  than  using  oblique  spherical 
triangles  to  calculate  each  segment  of  the  ship's  track. 

Figure  2-1  illustrates  a  general  overview  of  how  spherical  geometry 
is  employed.  A  ship's  track  along  the  surface  of  the  earth  is  made  into 
a  spherical  triangle  using  the  North  Pole,  the  point  of  departure  (A) ,  and 
the  point  of  arrival  (B)  as  vertices.  The  sides  of  this  triangle  are  com¬ 
prised  of  the  distance  in  degrees  of  arc  traveled  between  points  A  and  B, 
the  arc  from  point  A  to  the  North  Pole,  and  the  arc  from  point  B  to  the 
North  Pole.  The  two  arcs  from  the  given  points  to  the  Pole  are  equivalent 
to  the  colatitude  of  the  points.  A  closer  view  of  this  triangle  is  shown 
in  Figure  2-2. 

By  knowing  certain  sides  and  angles  of  this  spherical  triangle,  all 
other  unknown  sides  and  angles  can  be  solved  for.  The  main  algorithms 


Spherical  Triangle  Used 
for  Calculating  Ship's 
Geographic  Position 


Spherical  Geometry  Overview 


Point  of  Departure  in  Northern  Hemisphere 
North  Pole 


Lat2 


B 


A 

A  =  point  of  departure  (Lat^,  Lon^) 

B  =  point  of  arrival  (Lat2#  Lon^) 

90°  -  Lat^  =  Colatitude  of  point  A  - 
One  side  of  spherical  triangle 
(Measured  in  degrees  of  arc) 

90°  -  Lat2  =  Colatitude  of  point  B  - 
One  side  of  spherical  triangle 
(measured  in  degrees  of  arc) 

D  =  distance  traveled  on  the  surface  of  the  earth  between  A  and  B 
(measured  in  degrees  of  arc) 

ALon  =  the  difference  in  longitude  between  point  A  and  B. 

C  =  the  initial  course  of  the  ship. 


Figure  2-2.  North  Pole  Triangulation  Illustration 
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used  for  great  circle  sailing  computation,  which  are  actually  an  application 
of  spherical  triangle  geometry,  follow: 

(1)  hav  c  =  secLj  cosD  [hav  CoL^  -  hav  (D~CoL  )]  where  hav  represents 

1-ros 

the  haversine  function  ( — ~ — )  ,  C  is  the  initial  course,  Lj_  is  the 

latitude  of  the  point  of  departure,  L2  is  the  latitude  of  the  point 
of  arrival,  D  is  the  distance  between  these  two  points,  CoLj  is 
90°-L2  if  and  L2  are  both  in  the  same  hemisphere  and  90°+L2  if 
they  are  in  different  hemispheres,  D~  CoLj  is  the  absolute  difference 
between  D  ^nd  CoLj,  and  r-\_,  is  90°  -  L1# 

(2)  hav  D  =  hav  DL0  cosLj  cosL2  +  hav£  where  DLQ  is  the  difference 

in  longitude  and  £  is  the  difference  in  latitude  of  the  two  points. 


In  instances  where  the  initial  course  and  distance  between  points  are 
known,  the  values  of  the  latitude  and  longitude  of  point  B  may  be  computed 
by  rearranging  the  above  equations.  To  solve  for  the  latitude: 


„  T  secL, esc  D  cos  (D~CoL,)-l  +  cosC 

cosCoL,  =  - 1 - - - — - 1 - 


secLjCSCD 


To  solve  for  the  longitude: 


(4)  cosDLo  =  CosLi  cosL2  -  cos£  +  cosD 

COSLi  COSL2 


So  far  only  sailing  in  the  Northern  Hemisphere  has  been  taken  into 
consideration.  Although  calculations  are  identical  in  the  Southern  Hemisphere, 
the  spherical  triangle  itself  is  slightly  different  using  the  South  Pole 
as  one  of  its  vertices.  Figure  2-3  depicts  this  situation.  In  this  case, 
all  of  the  angles  and  sides  are  defined  the  same  except  for  angle  Cl  which 
is  equal  to  the  supplement  of  the  initial  course  angle  (180°  -  C) .  All 
of  the  computations  deal  with  the  latitudes  as  if  they  were  positive 
quantities.  If  latitudes  in  the  Southern  Hemisphere  are  solved  for,  a 
negative  sign  is  added  once  the  actual  calculation  is  complete.  For  cases 
where  the  point  of  departure  and  the  point  of  arrival  are  in  different 
hemispheres,  the  Pole  used  to  form  the  triangle  always  depends  on  the 
location  of  the  point  of  departure.  The  triangle  diagrams  for  these  cases 
are  illustrated  in  Figure  2-4.  At  the  present  moment,  geographic  position 
calculations  can  only  be  made  right  up  to  where  the  actual  crossing  of  the 
equator  occurs.  The  ability  to  cross  the  equator  is  not  currently  a  capa¬ 
bility  of  the  process  but  this  limitation  can  be  eliminated. 

Up  until  now,  a  general  overview  of  spherical  triangles  and  their 
application  to  calculating  latitude,  longitude  points  along  the  earth's 
surface  has  been  presented.  A  more  detailed  look  is  now  needed  into  the 
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South  Pole 


Point  of  Departure  in  Southern  Hemisphere  and 
Point  of  Arrival  in  Northern  Hemisphere. 

Figure  2-4.  North  &  South  Poles  Triangulation  Illustration 


actual  application  for  fathogram  processing.  Figure  2-1  illustrates  just 
one  spherical  triangle  across  a  large  portion  of  the  earth.  It  is  actually 
one  great  circle  sailing  route.  However,  since  most  ships  involved  in  this 
process  are  not  necessarily  following  one  great  circle  route,  not  just  one 
big  spherical  triangle  is  solved.  Instead,  many  very  small  triangles  are 
used  (Reference  Figure  2-5)  .  Every  time  the  navigational  log  gives  geo¬ 
graphic  positions  or  speed  changes  or  course  changes,  these  are  considered 
to  be  critical  points  along  the  ship's  track.  The  spherical  triangles 
solved  are  those  containing  critical  points  as  vertices. 

For  example,  take  the  simplest  case  where  two  geographic  positions 
along  the  ship's  track  are  given  and  no  speed  or  course  change  occurs 
between  these  points.  This  first  point  becomes  the  point  of  departure 
and  the  second  point  becomes  the  point  of  arrival  for  this  segment  of  the 
ship's  track.  Since  the  latitude  and  longitude  for  both  of  them  is  known, 
the  use  of  equation  (2)  makes  it  possible  to  solve  for  the  distance  be¬ 
tween  these  points.  Once  this  is  accomplished,  the  calculated  distance  is 
now  used  in  equation  (1)  to  solve  for  the  initial  course  angle.  This  shall 
be  referred  to  as  the  adjusted  course  of  the  ship  between  the  two  points. 
With  this  information  it  becomes  possible  to  calculate  the  latitude  and 
longitude  at  any  delta  time  interval  along  this  track  segment.  The  process 
involves  first  computing  the  distance  traveled  in  a  given  delta  time 
interval.  For  reference  purposes,  this  computed  distance  will  be  referred 
to  as  the  delta  distance  interval.  Next,  a  very  small  spherical  triangle 
is  constructed  using  the  delta  distance  interval  as  one  side,  the  known 
point  of  departure  as  A,  and  a  geographic  point  located  a  delta  distance 
interval  from  A  as  point  B.  Now  algorithms  (3)  and  (4)  can  be  used  in 
succession  to  solve  for  th<  latitude  and  longitude  of  point  B.  This  pro¬ 
cess  of  dividing  the  large  spherical  triangle  representing  a  track  segment 
into  smaller  ones  to  solve  for  latitude,  longitude  points  along  the  segment 
is  repeated  until  the  point  of  arrival  (at  the  end  of  the  segment)  is 
reached. 

Before  any  more  discussion  of  the  calculation  of  geographic  points  can 
continue,  another  topic  must  be  introduced.  As  stated  in  Section  2.5.1, 
a  judgment  as  to  what  navigational  data  can  be  considered  the  most  accurate 
must  be  made.  For  this  fathogram  process,  any  given  geographic  positions 
are  considered  to  be  the  most  correct  data.  Therefore,  whenever  possible, 
calculations  are  based  on  given  geographic  fixes.  Since  it  seems  arbitrary 
to  choose  the  integrity  of  given  courses  over  given  speeds  or  vice  versa, 
both  speeds  and  courses  are  adjusted  and  always  take  second  priority  to 
geographic  positions.  Thus,  tracks  are  broken  down  into  segments  with 
given  geographic  points  at  each  end.  These  segments  constitute  the  major 
spherical  triangles. 

Following  along  these  lines  of  thought,  it  becomes  necessary  to  break 
down  the  calculations  of  geographic  positions  into  three  major  cases. 


Instead  of  using  just  one  large  spherical  triangle, 
many  smaller  ones  are  used.  For  example,  triangles 
ANC,  CND ,  DNE,  ENF,  FNG,  GNH,  HNI ,  INJ ,  JNK,  KNL, 

LNM,  MNB  are  solved  independently.  AC,  CD,  DE,  EF, 

FG,  GH,  HI,  IJ,  JK,  KL,  LM,  MB  represent  track  segments 
which  comprise  the  entire  ship's  track  line. 


Figure  2-5.  Ship's  Track  Line 


The  first  case  is  one  in  which  no  speed  or  course  change  occurs  between  two 
given  latitude,  longitude  points.  The  solution  of  this  case  has  already 
been  thoroughly  discussed.  The  second  case  involves  the  situation  where 
only  speed  changes  occur  between  two  given  geographic  positions.  Therefore, 
the  geographic  positions  of  the  speed  changes  are  unknown.  The  solution 
for  this  case  requires  that  the  latitude ,  longitude  for  each  critical  point 
(point  where  the  speed  change  occurs)  be  calculated.  To  accomplish  this 
task,  the  total  distance  between  points  A  and  B  is  calculated  using 
algorithm  (2) .  Next,  the  given  speeds  and  times  between  critical  points 
are  used  along  with  the  computed  total  distance  of  the  track  segment  to 
proportionately  divide  the  segment  into  parts.  This,  in  essence,  adjusts 
the  speeds  between  the  critical  points. 

The  following  example  demonstrates  how  this  speed  adjustment  is  made. 
Assume  that  between  points  A  and  B  the  speed  changes  three  times.  The  points 
where  the  speed  changes  will  be  designated  as  PI,  P2,  P3.  Let  SI,  S2,  S3, 
and  S4  equal  the  speed  between  points  A  and  PI,  PI  and  P2,  P2  and  P3,  P3 
and  B  respectively.  In  the  same  manner,  let  Tl,  T2,  T3,  T4  equal  the 

time  interval  between  points  A  and  PI,  PI  and  P2,  P2  and  P3,  P3  and  B. 

Using  these  given  speeds  and  times/  calculate  the  distance  between  A  and  B 
with  the  following  relationship: 

DC  =  ATl(Sl)  +  AT2(S2)  +  AT3(S3)  +  AT4(S4). 

Next,  compute  the  actual  total  distance  (TD)  of  the  segment  using  algorithm 
(2) .  In  almost  every  case  DC  and  TD  will  differ  indicating  the  given  speeds 
are  inaccurate  and  need  adjusting.  The  next  step  is  to  compute  the 
following  ratios: 


FP1  =  ATI (SI) /DC 
FP2  =  AT2 (S2) /DC 
FP3  =  AT3 (S3) /DC 
FP4  =  AT4 (S4) /DC 


Using  these  fractional  parts  of  the  total  computed  distance,  the  adjusted 
distances  traveled  between  critical  points  can  be  calculated: 

D1  =  FP1  (TD) 

D2  =  FP2  (TD) 

D3  =  FP3  (TD) 

D4  =  FP4  (TD) 
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Once  these  distances  between  critical  points  are  computed,  the  location 
of  these  points  is  actually  designated  on  the  track  segment.  Each  part  of 
the  seqment  is  then  treated  as  a  separate  spherical  triangle.  Reference 
figure  2-6.  For  example,  points  A,  PI,  and  the  Pole  form  the  first  triangle 
taken  into  consideration.  Using  algorithms  (3)  and  (4) ,  the  latitude 
and  longitude  of  point  PI  is  computed.  Then  PI,  P2,  and  the  Pole  form 
the  naxt  triangle  and  the  geographic  position  of  P2  can  be  calculated. 

This  process  continues  until  all  critical  points  are  computed. 

These  critical  points  are  now  treated  as  if  they  were  given  geographic 
positions  with  no  speed  or  course  change j  between  them.  The  process  stated 
previously  for  calculating  the  latitude,  longitude  points  at  the  given 
delta  time  interval  is  employed  for  each  of  these  separate  spherical 
triangles.  It  should  be  noted  that  in  these  calculations  no  speed  change 
is  considered  more  accurate  than  any  other  since  that  would  be  an  arbitrary 
decision.  Therefore,  they  are  all  equally  taken  into  account. 

The  third  and  final  situation  that  must  be  dealt  with  is  when  course 
changes  occur  between  two  given  geographic  positions.  The  geographic 
positions  of  the  course  changes  are  unknown.  In  this  case  the  solution 
involves  many  steps  and  can  best  be  described  by  use  of  an  example.  In 
Figure  2-7-A,  points  A  and  B  are  the  two  known  points  between  which  the 
course  changes  two  times.  The  locations  of  these  course  changes  (critical 
points) ,  PI  and  P2,  are  unknown.  The  first  step  in  this  process  is  to 
compute  the  locations  of  Pi'  ,  P2*  ,  and  B1  ,  using  the  given  speeds,  courses, 
and  times.  These  are  designated  in  Figure  2-7-B.  As  can  be  seen  in  this 
figure,  the  location  of  the  calculated  B( labeled  b'  )  and  the  given  B  is  not 
the  same.  In  most  instances,  this  will  happen  since  input  data  is  often 
inaccurate.  Remembering  that  given  geographic  points  are  always  considered 
the  correct  locations,  an  adjustment  must  be  made  to  the  given  courses 
and  given  speeds  so  that  the  end  point,  B1  ,  will  be  located  correctly  at 
B.  Since  no  one  given  course  change  can  be  considered  more  correct  than 
any  other,  each  is  equally  taken  into  account  and  the  following  method  is 
employed  to  make  the  necessary  adjustments.  The  difference  in  latitude 
(&LAT)  and  the  difference  in  longitude  (ALONG)  is  calculated  between  points 
B  and  B1  (reference  Figure  2-7-C) .  If  these  delta  differences  are  within 
a  given  epsilon,  say  ten  seconds  of  arc,  then  no  further  adjustments  are 
necessary  and  Pi'  and  P2'  are  used  as  the  critical  points  (PI  and  P2).  On 
the  other  hand,  if  they  are  not  within  the  given  epsilon,  an  adjustment 
to  the  location  of  the  critical  points  results.  This  is  done  by  equally 
dividing  and  proportionately  adding  the  delta  latitude  and  longitude 
differences  to  each  calculated  critical  point  producing  Pi"  and  P2 
(reference  Figure  2-7-D) .  In  this  particular  example, 

Lat  of  PI"  =  (Lat  of  Pi’  )  +  ( ALAT/3) 

Lat  of  P2"  =  (Lat  of  P2’ )  +  2 (ALAT/3) 

Lat  of  B"  =  (Lat  of  B' )  +  3(ALAT/3)  =  (Lat  of  B')  +  ALAT 

The  longitude  is  calculated  in  a  like  manner. 


Example  of  a  Speed  Change  Segment  of  Track 


A,  B  -  Known  geographic  points  on  the  ship’s  track 
PI,  P2,  P3  -  Points  where  a  speed  change  occurs. 


Figure  2-6.  Example  of  a  Speed  Change  Segment  of  Track 


Thu  above  mentioned  adjustment  process  is  an  iterative  method  which 
comes  to  a  completion  when  the  calculated  end  point  falls  within  the 
epsilon  tolerance.  Once  the  geographic  positions  of  the  critical  point 
are  computed,  they  are  considered  to  be  known  latitude,  longitude  points. 

As  shown  in  Figure  2-8,  individual  spherical  triangles  are  formed  using 
these  critical  points  as  vertices.  The  previously  described  method  to 
solve  between  two  known  geographic  points  u  .th  no  speed  or  course  changes 
between  them  is  employed. 

It  is  possible  to  have  a  situation  where  both  course  and  speed  changes 
occur  between  two  known  geographic  positions.  When  this  happens,  it  is 
handled  as  if  it  were  a  case  of  course  changes  between  two  known  points. 

Since  this  method  automatically  adjusts  speeds  when  the  courses  are  adjusted, 
it  easily  lends  itself  to  a  course  and  speed  change  situation. 

2.5.3  Source  and  History  of  Approach 

The  great  circle  sailing  computation  algorithms  were  extracted  from 
American  Practical  Navigator  originally  by  Nathaniel  Bowditch,  published  by 
the  U.S .  Navy  Hydrographic  Office,  1958,  page  232.  This  entire  approach 
to  fathogram  processing,  however,  was  completely  developed  in-house  at 
Synectics  Corporation.  In  particular,  the  idea  of  working  completely 
in  a  geographic  reference  frame  and  computing  all  geographic  positions, 
not  as  if  they  were  located  on  a  flat  surface  chart  but,  as  they  actually 
occur  on  a  curved  earth  surface. 

2.5.4  Empirical  Results  and  Evaluations 

The  calculated  geographic  positions  appear  to  be  quite  accurate. 

Two  factors  contribute  to  this  accuracy.  One,  all  computations  take  into 
account  the  curvature  of  the  earth's  surface.  This  is  accomplished  by 
employing  oblique  spherical  triangles  which  deal  with  distances  in  degrees 
of  arc  on  the  earth's  surface,  not  X,Y  values  on  a  plane.  Two,  by 
calculating  points  along  the  earth's  surface  and  not  on  a  X,Y  plane,  all 
results  are  in  geographies.  Therefore,  processing  through  more  algorithms 
to  produce  geographic  points  from  X,Y  coordinates  is  not  necessary. 

Of  course,  it  should  be  stressed  that  the  results  are  only  as  accurate 
as  the  navigational  data  used  as  input. 


Example  of  a  Course  Change  Segment  of  Track 


A,  B  -  Known  geographic  positions  on  the  ship's  track. 
PI,  P2  -  Points  where  a  course  change  occurs. 


Figure  2-8.  Example  of  a  Course  Change  Segment  of  Track 


,  SECTION  3.  SOFTWARE  ACCOMPLISHMENTS 


3.1  PURPOSE 


The  purpose  of  this  section  is  to  discuss  some  of  the  more  interesting 
developments  which  have  occurred  during  the  creation  of  the  BDRS  software. 
The  discussions  included  are  not  intended  to  exhaust  all  facets  of  the 
system.  The  focus  of  each  separate  discussion  will  be  from  the  key  novel 
capabilities  provided  by  the  software  in  satisfying  the  requirements  of 
the  three  BDRS  subsystems;  digitization  and  voice  entry,  batch,  and 
data  base. 


3.2  DIGITIZATION  AND  VOICE  ENTRY  SUBSYSTEM 


3.2.1  Data  Entry 

The  key  accomplishment  of  this  BDRS  subsystem  is  that  of  providing 
the  capability  to  digitize  sounding,  discrete  point  and  trace  data  from 
nautical  charts.  This  data  is  then  stored  in  a  compact  and  conveniently 
accessible  form.  Sounding  values  may  be  entered  manually  with  a  keyboard 
or  vocally  using  the  Threshold  500  Voice  Recognition  device.  When  using 
the  voice  station  the  sounding  given  will  be  displayed  on  the  cursor  display. 
If  the  sounding  was  entered  vocally,  it  will  also  appear  on  the  Threshold 
500  Voice  Recognition  display. 

To  physically  record  a  sounding  or  discrete  point  the  user  has  three 
options  to  choose  from.  The  data  may  be  entered  manually  using  the  keyboard, 
or  the  pushbuttons  on  the  cursor.  Using  the  voice  box  is  the  third  option 
available.  As  the  data  is  entered  a  visual  display  is  provided  at  the 
Tektronix  4010  display  unit.  The  display  cursor  flashes  the  sounding  value 
on  its  display  indicating  the  data  has  been  entered.  This  eliminates  the 
need  for  a  user  to  continually  look  at  the  Tektronix  4010  display  unit. 

The  sounding  data  may  also  be  edited  by  the  user  in  a  very  simple  way 
using  either  the  special  key  board  or  the  'voice  box'.  Thus,  a  complete 
capability  is  provided  to  create  and  edit  sounding  data  which  makes  maximum 
use  of  system  resources  to  ease  the  task  of  the  user  in  data  entry  and  edit. 


3.2.2  Fathograms 

An  important  capability  of  this  BDRS  subsystem  is  that  of  digitizing 
fathograms;  that  is,  graphs  of  depth/time  coordinates  supplemented  with  such 
parameters  as  geographic  fixes,  loxodrome  bearings,  and  ship  velocities. 

Once  a  digitized  fathogram  file  has  been  created,  a  file  of  geographic-depth 
positions  can  be  constructed  and  entered  into  a  data  base.  Thus,  the  analog 
information  of  the  fathogram  is  integratable  into  the  general  BDRS  data  base 
framework. 


3.2.3  Registration 


The  algorithm  of  registration  has  been  thoroughly  discussed  in  Section 
2.2  of  this  document .  It  should  however  be  emphasized  here  that  the 
development  and  implementation  of  this  algorithm  within  this  subsystem  pro¬ 
vides  the  subsystem  user  a  very  efficient  and  easily  employed  method  of 
registering  charts  so  that  information  in  a  feature  digitized  from  that  chart 
is  easily  accessed  and  accurately  edited.  In  the  Lineal  Input  System  (LIS) 
no  such  method  was  employed,  and  the  errors  inherent  in  both  the  LIS  day  '1' 
and  day  'n'  registration  procedures  have  been  eliminated.  Within  the  con¬ 
ceptual  structure  of  the  registration  scheme  developed  by  Synectics 
Corporation,  it  could  become  an  easy  matter  to  edit  table  files  even  when 
they  are  created  by  the  batch  program  which  converts  arbitrary  geographic 
files  to  table  files.  Thus,  at  some  later  date,  an  arbitrary  geographic 
file  constructed  from  information  in  the  data  base  could  be  converted  to 
table  form,  edited,  and  reconverted  to  geographic  coordinates. 


3.2.4  Review  Mode 


The  capability  exists  to  display  the  data  of  a  table  file  on  a 
Tektronix  4010  display  given  a  user  selected  window.  Each  feature,  whether 
consisting  of  trace  data,  discrete  points,  or  soundings,  is  searched  and 
data  which  falls  within  the  window  is  displayed.  This  provides  the  user 
with  all  he  needs  to  discover  where  he  desires  to  make  edit  changes. 


3.3  BATCH  PROCESSES  SUBSYSTEM 

3.3.1  Fathogram  Processing 

The  unique  feature  of  this  process  is  that  a  geographic  file  of 
position/depth  points  is  created  as  output.  Up  until  this  time  any  other 
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fathogram  process  has  output  points  in  X,Y,  depth  format  and,  in  order  to 
get  a  geographic  position,  the  X,Y  points  had  to  be  processed  through  a  pro¬ 
jection  transformation.  As  can  be  readily  seen,  this  old  method  had  two 
drawbacks.  One,  two  processes  were  needed  to  obtain  geographic  output, 
and,  two,  since  X,Y  points  were  computed,  it  assumed  the  earth  to  be  a 
plane  and  not  a  curved  surface.  Calculations  were  based  on  the  ship's 
track  being  drawn  on  a  chart.  In  contrast,  BDRS  fathogram  processing 
bases  all  track  calculations  on  a  curved  surface  which  much  better  represents 
the  true  surface  of  the  earth.  Also,  this  single  fathogram  process  deals 
completely  in  the  geographic  realm. 

Another  capability  of  fathogram  processing  is  that  it  can  be  used  as 
a  tool  to  quickly  evaluate  the  data  being  processed.  This  capability  is 
greatly  needed  since  the  accuracy  of  the  fathogram  data  is  often  questionable 
as  stated  in  Section  4. 2. 1.2.  During  the  fathogram  processing  itself,  a 
report  to  the  CRT  screen  signals  any  course  or  speed  adjustment  that  is 
greater  than  user  defined  bounds.  If  desired,  the  process  can -be  aborted 
immediately  and  the  data  evaluated  as  poor.  Also,  at  the  end  of  th^  run 
a  report  to  the  line  printer  indicates  the  largest  course  and  speed  adjust¬ 
ment  made.  If  the  adjusted  courses  and  speeds  are  much  different  from  the 
given  courses  and  speeds,  this  is  a  good  indication  that  the  data  is  poor. 
Figure  3-1  depicts  an  example  CRT  display  of  the  above  mentioned  operation. 

Data  can  also  be  evaluated  once  the  fathogram  process  is  complete  by 
visual  inspection  of  the  ship's  track  line  which  can  be  easily  displayed  on 
the  CRT  screen  using  the  routine  "TESTPLOT."  If  the  track  line  suddenly 
changes  direction  and  there  is  no  indication  of  such  a  course  change  in  the 
ship's  navigational  log,  then  the  accuracy  of  the  given  data  is  highly 
questionable.  An  example  of  this  track  line  output  is  displayed  in  Figure 
3-2.  The  ship's  navigational  log  stated  all  of  the  courses  ranged  between 
115°  and  120°,  yet  the  track  line  definitely  changes  course  drastically. 

An  inspection  of  the  log  data  resulted  in  proof  that  obvious  course  changes 
were  completely  left  out  of  the  log  data.  This  causes  the  accuracy  of  the 
data  to  become  suspect.  If,  however,  the  track  line  and  adjusted  courses 
and  speeds  are  very  close  to  the  given  data,  then  the  data  is  probably 
reliable. 


3.3.2  Plot  Functions 


The  plot  software  has  several  features  worthy  of  especial  notice.  The 
development  of  this  software  is  such  that,  in  principle,  any  other  type  of 
plotter  can  be  added  to  the  BDRS  hardware  configuration  simply  by  accessing 
an  intermediate  plot  file.  Second,  the  Xynetics  interface  routines  are 
written  in  simple  Fortran  and  are  in  principle,  usable  by  other  conputer 
systems.  Finally,  the  development  of  further  plot  functions  is  readily 
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Figure  3-1.  Adjusted  Course  Display 


3-2.  Track  Line  Output  From  Fathogram  Processing 


integratable  into  the  current  software  due  to  the  simple  calling  sequence 
of  any  plot  function.  For  example,  functions  existing  on  other  computer 
systems  interfacing  with  a  Calcomp  plotter  may  be  integrated  into  the  BDRS 
system  to  produce  the  same  type  of  output. 


3.3.3  Depth  Adjustment 

Two  useful  features  are  provided  by  this  capability.  One,  it  offers 
a  means  by  which  incoming  depth  data  can  be  evaluated  before  being  entered 
into  the  data  base.  Two,  if  necessary,  it  adjusts  the  depths  according 
to  user  defined  criteria  and  outputs  the  results  in  a  standard  formatted 
BDRS  geographic  file.  Since  this  new  adjusted  file  is  stored  on  disk,  its 
creation  has  no  affect  on  the  data  base  data.  If  desired,  it  can  be  loaded 
into  the  data  base  or  discarded  completely. 

To  fully  understand  how  these  features  are  implemented,  a  short  expla¬ 
nation  of  the  depth  adjustment  process  is  necessary.  This  process  is 
executed  in  several  phases.  The  first  phase  is  to  convert  the  data  to  be 
adjusted  to  a  geographic  reference  frame  and  to  acquire  the  geographic 
bounds  of  this  data.  This  is  accomplished  by  performing  a  BDRS  table  to 
geographic  conversion.  The  next  phase  is  to  section  the  BDRS  Geographic 
Data  Base  utilizing  the  geographic  bounds  from  above.  These  two  files  are 
then  used  as  input  to  the  Depth  Adjustment  function.  Next,  a  grid  system 
containing  delta  latitude,  longitude  grid  matrix  buckets  is  created  over 
the  geographic  area  in  question.  Each  grid  matrix  bucket  represents  a  random 
record  stored  on  disk  and,  in  most  instances,  covers  a  four  minute  latitude 
value  by  a  four  minute  longitude  value.  A  limiting  factor  of  32767  random 
records  per  file  exists.  Therefore,  if  the  four  minute  bucket  size  produces 
more  than  32767  grid  buckets  for  the  given  geographic  area,  the  bucket  size 
is  increased  by  one  minute  until  there  are  less  than  32767  buckets  (random 
records)  per  area.  In  Figure  3-3  a  geographic  area  containing  25°  of 
longitude  and  5°  of  latitude  is  represented  using  this  grid  system.  It 
consists  of  375  x  75,  or  28125  grid  buckets  each  four  minutes  by  four 
minutes  in  size. 

Once  the  grid  system  is  created,  the  sounding  data  within  the  geo- 
sectioned  file  is  processed  to  average  depths  within  each  grid  bucket. 

This  is  accomplished  by  calculating  and  storing  in  each  random  record 
(grid  bucket)  the  sum  of  the  soundings  and  total  number  of  soundings  located 
in  each  bucket.  The  next  phase  of  this  program  is  to  input  process  the 
geographic  data  needing  adjustment.  The  grid  bucket  address  of  each 
sounding  is  computed  and  then  the  sounding  value  itself  is  compared  to  the 
grid  bucket  averaged  sounding.  If  the  input  sounding  does  not  meet  user 
input  criteria,  the  sounding  value  is  adjusted.  A  variety  of  adjustment 
options  are  available  and  more  can  easily  be  implemented  if  such  additional 


options  seem  warranted.  As  the  data  points  are  adjusted,  they  are  output 
processed  in  their  original  geographic  position.  No  geographic  position 
adjustment  is  made  due  to  the  fact  that  the  adjustments  are  arbitrary. 

That  is,  no  judgment  to  the  validity  of  each  geographic  position  can  scien¬ 
tifically  be  calculated. 

This  process  can  easily  be  implemented  as  an  evaluation  tool  since  a 
final  printed  report  indicates  the  percentage  of  soundings  that  were  adjusted. 
Obviously,  if  a  large  percentage  were  adjusted,  then  the  data  may  be 
evaluated  as  poor  compared  to  that  stored  in  the  data  base.  If  the  com¬ 
parison  percentage  range  is  made  extremely  small,  then  all  but  very  accurate 
data  will  be  adjusted.  An  even  closer  analysis  of  the  data  can  be  made  by 
using  as  input  a  sectioned  file  that  has  been  geo-sectioned  using  a  high 
evaluation  code.  In  this  case,  only  extremely  accurate  data  base  soundings 
will  be  used  for  comparison  purposes.  Thus,  the  accuracy  of  incoming  data 
can  be  quickly  ascertained  with  use  of  the  depth  adjustment  process. 


3.4  DATA  BASE  SUBSYSTEM 


The  highlight  of  the  BDRS  data  base  subsystem  is  its  ability  to  support 
the  access  and  retrieval  of  a  user  defined  random  geographic  area.  Such  a 

capability,  which  has  far  reaching  potential  for  exploitation,  envolves 
the  extensive  utilization  of  mapping  and  sectioning  algorithms  which  are 
in  affect  the  nucleus  of  the  entire  data  base  process.  In  the  sub-sections 
that  follow,  an  attempt  will  be  made  to  provide  the  reader  with  a  better 
understanding  of  what  the  Synectics '  developed  algorithms  do  and  how  they 
support  the  overall  data  base  process.  Part  1  of  the  discussion  will  con¬ 
centrate  on  the  flow  of  data  in-to  and  out-of  the  BDRS  data  base,  high¬ 
lighting  those  periods  of  the  process  which  envolve  the  use  of  the  mapping 
and  sectioning  algorithms.  Parts  2  and  3  will  attempt  to  detail  the 
individual  processes  of  mapping  and  sectioning. 


3.4.1  Data  Flow 


The  flow  of  data  through  the  BDRS  data  base ,  as  depicted  in  Figure  3-4 , 
may  be  segmented  into  the  six  (6)  major  processes  or  operations:  1)  Source 
Evaluation;  2)  Input  of  Document/Source  Description  Information; 

3)  Digitization  (Analog  to  X,Y  conversion) ;  4)  Conversion  and  Input 
Processing;  5)  Document/Source  Review  and  Modifications;  and  6)  Geographic 
Sectioning/Product  Generation.  Each  process  corresponds  to  the  numbered 
process  flow  illustrated  in  Figure  3-4  and  envolves  the  following: 

1)  Source  Evaluation  -  This  off-line  process  envolves  the  review  of 
selected  analog  source  for  the  purpose  of  accummulating  that 
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information  required  to  adequately  describe  the  document.  If  the 
selected  source  is  to  be  input  into  the  data  base,  such  infor¬ 
mation  is  required  by  the  on-line  data  base  INPUT  process.  With¬ 
out  it,  entry  into  the  data  base  will  be  denied.  Required  infor¬ 
mation  includes  such  items  as:  Source  ID,  Platform  Name,  Sheet 
Number,  Document  Bounding  Rectangle,  Navigational  Aids,  etc. 
Reference  Appendix  C  of  this  document  for  a  detailed  description 
of  the  document  and  source  description  records. 

2)  Input  of  Document/Source  Information  -  Once  the  select  source 
(document)  has  been  evaluated  and  the  appropriate  information 
assembled,  it  can  be  input  to  the  data  base  via  the  ON-LINE 
data  base  process  (Step  2,  Figure  3-4).  This  process,  which 
involves  the  use  of  the  mapping  algorithm,  interactively  constructs 
and  stores  in  the  data  base  a  document  description  record  and  one 
or  more  source  description  records  for  the  selected  document. 
Additionally,  using  the  documents  bounding  geographic  rectangle 
which  was  input  as  part  of  the  document  description  record,  the 
geographic  reference  to  the  document  is  constructed  via  a  call 

to  the  mapping  algorithm.  This  "MAPPING"  process  envolves 
the  use  of  a  450  x  225  grid  which  equates  to  the  entire  surface 
of  the  earth.  The  document  being  mapped,  is  logically  positioned 
on  the  grid  relative  to  its  geographic  location  and  the  corres¬ 
ponding  grid-cell  numbers  are  noted.  Each  cell  of  the  grid  has 
a  pseudo  data  record  associated  with  it  within  the  geographic 
sub-index  of  the  data  structure.  The  purpose  of  this  record  is 
to  accumulate  those  document  numbers  that  were  identified  by 
mapping  as  residing  within  the  cell.  Hence,  the  final  step  of 
the  mapping  process  is  to  add  to  each  record  the  document  number 
of  the  newly  mapped  source.  Once  this  entire  process  has  been 
completed,  the  data  base  is  now  ready  to  receive  the  digital 
data  associated  with  the  document.  Figure  3-5  offers  a  graphic 
illustration  of  the  "Mapping"  process. 

3)  Digitization  - 
and 

4)  Conversion  and  Input  Processing  -  The  digitization/X,Y  to  geo¬ 
graphic  conversion  processes  are  depicted  as  steps  3  &  4,  Figure 
3-4.  This  process  involves  the  conversion  of  selected  analog 
source  material  to  a  form  capable  of  being  loaded  into  the  BDRS 
data  base  (BDRS  formatted  Standard  Geographic  format) .  Once  the 
digitization/editing  operation  has  been  completed,  the  file  is 
input  to  the  batch  table-to-geographic  conversion  process.  The 
resultant  file  is  then  loaded  into  the  data  base  via  the  batch 
Input-Process  function.  If  this  process  is  to  be  completed 
successfully,  step  2  must  have  already  been  completed  without 
error.  Note  that  neither  the  Mapping  nor  the  Sectioning  algo¬ 
rithms  are  used  during  these  processes. 
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5)  Document/Source  Review  and  Modification  - 
and 

6)  Geographic  Sectioning/Product  Generation  -  Two  access  methods  are 
available  to  the  user  for  purposes  of  data  retrieval  and  review. 

The  first,  and  most  straightforward  method,  is  retrieval  by 
document  number.  This  capability  allows  the  user  to  access  the 
data  in  its  virgin  form.  It  is  in  no  way  tied  to  geographies 
and  for  tnat  reason,  does  not  require  the  support  of  the  Mapping 
or  Sectioning  algorithms.  The  second,  and  most  powerful  method 
of  access  is  by  random  geographies.  This  process,  which  may  be 
executed  in  varying  forms  from  either  the  master  console,  6052 
CRT,  or  4014  Graphic  CRT,  is  accomplished  using  the  following 
sequence  of  programmed  operations: 

^  The  user  is  asked  to  define  his/her  geographic  area  of  interest. 
This  can  be  in  the  form  of  a  circle,  path,  or  3  to  8  sided 
polygon. 

^  The  mapping  routine  is  then  called  to  perform  the  mapping 
operation.  This  process  is  nearly  identical  to  the  one 
discussed  in  step  2,  with  the  only  exception  being  that  instead 
of  passing  the  bounding  rectangle  of  a  new  document,  we  are 
passing  a  user  defined  area  of  interest.  The  end  result  of 
the  process  is  that  mapping  identifies  those  grid  cells  which 
are  in  or  around  the  user  defined  geo  area.  Figure  3-6 
graphically  depicts  some  typical  mapping  examples. 

^  A  pseudo  data  record,  which  resides  within  the  data  structure 
for  each  geo-cell,  is  then  read  from  those  cells  identified  by 
mapping  as  having  fallen  within  the  user  area.  The  document 
numbers  stored  in  each  record  are  accumulated  in  an  internal 
buffer  until  all  cell  records  have  been  processed.  The  end 
result  of  such  a  cycle  is  the  creation  of  an  internal  array 
containing  the  document  numbers  of  those  charts  stored  in 
the  data  base  which  fall  within  (or  around)  the  user  area  of 
interest. 

J  Now  that  the  candidate  documents  have  been  identified,  the 
process  which  involves  the  use  of  "Sectioning"  may  begin. 

Each  candidate  document  number  is  used  to  retrieve  their 
respective  document  description  records.  Once  this  is  done, 
sectioning  compares  the  bounding  rectangle  of  the  document 
to  that  of  the  user  defined  geographic  area.  At  this  point, 
a  determination  is  made  by  sectioning  as  to  whether  or  not 
the  document  resides  within  the  select  area.  If  it  does, 
the  digital  data  for  that  document  is  directed  to  the 
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appropriate  destination  and  the  cycle  of  processing  candidate 
documents  continues.  If  it  does  not,  the  document  is  dis¬ 
carded  and  the  process  goes  on.  The  end  result  of  this  process, 
depending  on  the  request  type,  could  be  in  the  form  of  a 
graphic  display  on  the  4014  CRT  or  a  disk  resident  BDRS 
formatted  Geographic  file. 


3.4.2  Mapping 

The  need  to  provide  the  BDRS  data  base  user  with  a  random  geographic 
access  capability  was  the  motivating  factor  behind  the  development  of  the 
"Mapping"  algorithm.  This  algorithm  provides  the  mechanism  through  which 
digital  holdings  may  be  associated  with  geographic  locations  without 
physically  shredding  the  input  processed  file. 

The  mapping  algorithm  views  the  earth  as  a  flat  surface  and  divides 
it  into  a  grid.  Each  cell  of  the  grid  represents  48  minutes  of  longitude 
by  48  minutes  of  latitude.  This  divides  the  earth  into  225  grid  cells  of 
latitude  and  450  cells  of  longitude.  Each  grid  line  is  numbered  consecu¬ 
tively  in  each  direction,  beginning  in  the  lower  left  corner  of  the  grid 
(Figure  3-7) .  This  number  is  then  used  throughout  the  mapping  process 
to  identify  a  specific  area  of  the  earth. 

The  48  minute  grid  was  chosen  because  it  was  found  to  be  the  best 
suited  for  the  type  of  charts  and  other  sources  of  data  the  BDRS  would 
use.  It  should  be  noted  that  the  size  of  the  chart  does  not  affect  the 
mapping  process  in  any  way.  What  is  affected  is  the  amount  of  processing 
that  must  be  done.  A  chart  that  is  four  degrees  of  longitude  by  four 
degrees  of  latitude  would  cover  a  minimum  of  twenty-five  grid  cells  using 
a  48  minute  grid.  A  ten  minute  grid  using  the  same  chart  would  include 
a  minimum  of  576  cells.  Since  each  grid  cell  requires  processing,  the 
smaller  the  grid  size  the  greater  the  processing  time.  However,  if  charts 
covered  an  area  of  one  minute  of  latitude  and  longitude  it  would  be 
worthwhile  to  change  to  a  smaller  grid.  Enlarging  the  grid  would  reduce 
the  number  of  cells  that  would  be  processed.  However,  a  larger  grid 
scheme  would  allow  more  documents  to  fall  in  any  single  cell,  thus  in¬ 
creasing  the  number  of  documents  that  would  have  to  be  processed.  Con¬ 
sidering  the  problems  that  could  be  created  by  the  size  of  the  grid,  the 
48  minute  scheme  proved  an  effective  size  for  the  BDRS. 

As  stated  earlier,  mapping  is  used  to  retrieve  as  well  as  input  into 
the  data  base.  The  process  begins  with  the  geographic  coordinates  that 
define  a  circle,  path,  or  polygon.  The  coordinates  are  converted  to 
seconds  of  arc  and  mapped  onto  the  grid.  The  grid  can  now  be  seen  to 
represent  an  X,Y  grid  with  the  rows  representing  the  Y  value  and 
columns  representing  the  X  value.  This  concept  is  illustrated  in 
Figure  3-7.  The  method  for  determining  which  cells  are  used  is  dependent 
on  the  type  of  search  being  performed. 
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In  a  circle  search  the  radius  is  first  computed  and  used  to  give  the 
minimum  and  maximum  latitude  and  longitude  values  of  the  area.  It  is  now 
possible  to  look  at  each  column  of  grid  cells  defined  by  the  min/max  values. 
Beginning  with  the  left  side  an  array  stores  the  minimum  and  maximum  cell 
numbers  and  all  those  that  fall  in  between.  This  produces  a  square  area 
covering  the  circle  as  illustred  in  Figure  3-8. 

Polygon  searches  are  handled  in  a  different  manner  in  order  to  find 
the  smallest  number  of  cells  for  the  area.  This  is  accomplished  by  calcu¬ 
lating  the  slope  of  the  line  between  two  points  forming  a  side  of  the  polygon. 
Using  the  slope  it  is  possible  to  determine  algebraically  through  which  grid 
cells  the  line  will  pass  for  each  side  of  the  polygon.  Starting  at  the 
left  hand  side  of  the  polygon  each  column  of  cells  is  examined  to  find  the 
minimum  and  maximum  cells  for  that  column.  These  cell  numbers  are  stored 
in  an  array  with  those  additional  cells  that  fall  in  between.  The  process 
is  repeated  for  each  column  the  polygon  passes  through. 

Path  searches  use  the  same  process  as  the  polygon  except  for  a  pre¬ 
liminary  step.  The  path  is  given  by  three  points,  two  end  points  and  one 
side  point.  Four  corners  are  determined  from  the  three  points.  The  path 
now  represents  a  four  sided  polygon  and  follows  the  polygon  processing 
just  discussed. 

Mapping  at  this  point  has  built  an  array  of  grid  numbers  that  cover 
the  area  of  interest.  The  array  can  then  be  used  as  a  sub-index  for  in¬ 
putting  into  the  data  base  or  building  an  array  of  document  numbers. 

Figure  3-9  gives  an  overall  picture  of  the  mapping  function. 

The  problem  that  mapping  creates  is  when  a  search  area  crosses  the 
international  date  line.  This  case  is  illustrated  in  Figure  3-10.  When 
this  situation  arises,  the  minimum  and  maximum  bounds  of  the  area  will  be 
computed  and  result  in  a  reverse  image  of  the  intended  area.  This  was 
corrected  by  testing  for  the  condition  and  adjusting  the  values. 


3.4.3  Sectioning 

Mapping  has  provided  the  means  of  identifying  those  documents  that  fall 
in  or  around  an  area.  However,  some  of  these  documents  will  not  necessarily 
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fall  entirely  inside  the  area.  Figure  3-6  shows  how  mapping  will  include 
documents  that  fall  outside  the  area  and  partially  inside  the  area. 
Sectioning  therefore  takes  documents  one  at  a  time  and  determines  one  of 
three  conditions;  all  in,  all  out,  or  partial.  The  mathematical  procedures 
used  in  sectioning  have  previously  been  described  in  detail  in  Section  2 
of  this  document.  Therefore,  the  following  discussion  will  deal  with  the 
concept  and  problems  present  in  the  sectioning  algorithm. 

A  bounding  rectangle  describes  a  polygon  around  the  data.  For  example, 
a  document  bounding  rectangles  are  given  when  the  user  inputs  the  geographic 
bounds  of  the  document.  This  confines  the  data  to  a  specific  area  on  the 
surface  of  the  earth.  In  addition  to  the  document,  there  exists  feature 
bounding  rectangles.  A  feature  is  essentially  a  string  of  data  that  has 
been  digitized  contiguously.  As  the  feature  is  being  digitized,  each  point 
is  compared  to  find  a  minimum,  maximum  latitude  and  longitude.  These 
values  are  what  determine  the  bounding  rectangle  of  the  feature,  as  shown 
in  Figure  3-11.  When  sectioning  is  called  it  takes  the  points  that  form 
the  bounding  rectangle  and  calculates  the  status  as  being  all  in,  all  out, 
or  partial.  Therefore,  the  test  points  used  by  sectioning  are  the  points 
defining  the  bounds  of  a  document,  or  the  min/max  values  of  a  feature. 

When  the  sectioning  algorithm  is  called  it  determines  which  condition 
exists  for  the  data  being  tested.  If  a  document  falls  all  in  the  area, 
there  is  no  need  for  further  testing.  All  the  data  for  that  document  will 
be  written  to  a  disk  file.  If  a  document  is  found  to  be  out  of  the  area, 
then  it  is  disregarded.  However,  if  a  document  is  found  to  be  partially 
in,  further  processing  is  needed  to  determine  what  part  of  the  document 
fulls  inside. 

To  do  this  sectioning  moves  down  a  level  in  the  data  structure, 
testing  each  feature  of  the  document.  If  a  feature  is  in,  it  is  written 
to  the  disk  file,  if  it  is  out  it  is  bypassed.  A  feature  that  rests 
partially  in  causes  sectioning  to  move  down  another  level  in  the  data 
structure.  At  this  level  each  point  in  the  feature  is  tested  to  see 
if  it  is  in  or  out  and  writes  the  appropriate  data  to  disk. 

This  process  continues  for  all  the  documents  that  reside  in  the  area 
of  interest,  with  the  end  result  a  new  BDRS  geographic  file. 


During  the  retrieval  process,  certain  conditions  will  arise  that  must 
be  checked  for.  These  special  cases  will  now  be  discussed  along  with 
the  derived  solution  for  each. 
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Using  the  test  points  sectioning  calculates  where  each  point  falls 
relative  to  the  search  area.  Figure  3-12  illustrates  a  document  that 
has  one  test  point  within  the  search  area.  If  at  least  one  point  falls 
inside  the  area  the  document  is  at  least  partially  in.  However,  as  shown 
in  Figure  3-13,  conditions  will  exist  where  all  the  test  points  fall  outside 
the  search  area  and  the  bounding  rectangle  is  partially  inside. 

To  solve  for  this  condition,  the  line  formed  by  two  test  points  is 
tested  to  see  if  it  crosses  any  of  the  lines  of  the  polygon.  If  there 
is  at  least  one  intersection  of  lines  then  the  bounding  rectangle  is 
partially  in. 

Even  if  the  bounding  rectangle  fails  the  check  just  discussed  it  could 
still  be  partially  in  as  depicted  in  Figure  3-14.  In  this  case  the 
bounding  rectangle  totally  encompasses  the  search  area.  The  first  test 
by  sectioning  will  find  no  test  points  within  the  area,  and  the  second 
test  will  find  no  lines  crossing.  This  problem  is  as  common  to  the  path 
and  polygon  searches  as  it  is  to  the  circle. 

In  polygon  searches,  the  solution  is  to  reverse  the  points.  What  is 
done  is  to  check  if  any  of  the  points  of  the  polygon  search  area  fall 
inside  the  bounding  rectangle.  As  illustrated  in  Figure  3-14,  the  polygon 
search  area  falls  inside  the  bounding  rectangle,  which  proves  the  bounding 
rectangle  is  partially  in. 

The  solution  to  the  circle  (Figure  3-14)  is  to  use  the  center  point 
as  a  ter'-  point.  If  the  center  of  the  circle  is  within  the  bounding 
rectangle  then  the  feature  or  document  is  partially  in. 

Additional  problems  can  exist  when  using  the  circle  searches.  With 
this  type  of  search  the  distance  between  the  center  of  the  circle  and  a 
test  point  is  calculated.  If  the  distance  is  less  than  or  equal  to  the 
radius  of  the  circle,  the  point  is  in.  It  is  possible  for  the  distance 
to  the  test  points  to  be  greater  than  the  radius  and  the  bounding  rectangle 
still  falls  within  the  search  area  (Example  A,  Figure  3-15). 

The  solution  is  to  determine  the  equation  of  the  line  between  two  test 
points  and  calculate  the  distance  from  the  center  point  to  the  line. 

If  the  distance  is  less  than  the  radial  distance  the  area  could  be  partially 
in.  However,  this  solution  creates  another  problem  as  shown  in  Example  B 
of  Figure  3-15.  The  problem  arises  when  the  distance  from  center  point 
to  the  line  is  computed.  We  create  imaginary  lines  which  appear  to  be 
within  the  circle  but  really  do  not  exist.  The  solution  is  to  begin 
comparing  the  center  point  to  the  actual  end  points  of  the  line  being 
tested.  If  the  center  point  does  not  fall  between  two  end  points  the 
status  is  all  out. 
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EXAMPLE  OF  A  SINGLE  TEST  POINT 
WITHIN  AN  AREA  OF  INTEREST 


WITH  TEST  POINTS  OUTSIDE  THE  AREA  OF  INTEREST 


Figure  3-14,  Problem  of  Bounding  Rectangles  Larger 

Than  Area  of  Interest 
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Fiqure  3-15.  Circle  Search  Problems 


As  described  in  Section  2  of  this  document,  sectioning  converts 
geographic  values  to  cartesian  X,Y,Z  coordinates  on  the  surface  of  a  unit 
sphere  which  gives  the  coordinates  in  terms  of  spherical  angles.  The  use 
of  spherical  angles  creates  a  problem  when  a  search  area  crosses  zero 
longitude.  The  spherical  angle  of  longitude  values  is  0  for  0°  longitude 
and  increases  in  an  easterly  direction  until  a  complete  revolution  around 
the  earth  is  made.  Therefore,  zero  longitude  represents  the  minimum  and 
maximum  spherical  angle  that  could  exist  for  any  longitude  value.  When 
sectioning  computes  the  minimum  and  maximum  values  of  a  search  area  that 
crosses  0°  longitude,  it  will,  in  effect,  produce  a  reversed  image  (Figure 
3-16) .  For  example,  if  an  area  between  2°W  and  2°E  was  sectioned,  the 
spherical  angles  produced  would  be  6.25  and  .035  respectively.  When 
comparing  these  angles,  the  algebraic  minimum  value  is  that  of  the  2°E 
longitude.  This  results  in  a  sectioned  area  between  2°E  and  2°W  instead 
of  the  desired  area  between  2°W  and  2°E.  In  addition  to  this,  any  document 
that  is  in  the  eastern  hemisphere  with  one  side  at  zero  longitude  would  be 
viewed  as  a  reverse  image.  This  problem  is  easily  corrected  by  comparing 
the  geographic  values  to  check  for  this  condition.  If  the  conditions  exist 
appropriate  adjustments  are  made  allowing  sectioning  to  continue. 

The  solutions  to  the  problems  associated  with  sectioning  provide  a 
full  capability  to  perform  geographic  retrievals.  The  only  restrictions 
that  are  placed  upon  the  user  are  mathematical  in  nature.  These  are  -  the 
points  must  be  entered  in  a  clockwise  direction  (beginning  on  the  left 
hand  side  if  a  polygon  search) ,  and  cannot  form  internal  angles  greater 
than  180°.  However,  no  geographic  restrictions  exist.  The  search  area 
can  be  as  large  as  the  total  surface  of  the  earth  or  as  small  as  desired. 
Invalid  conditions  are  checked  for  and  rejected  such  as  the  input  points 
being  the  same  or  when  they  form  a  straight  line.  This  enables  users  to 
successfully  and  accurately  retrieve  any  geographic  area  using  circle, 
path,  or  polygon  searches. 
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SECTION  4.  THE  PROBLEMS  OF  ACCURACY 


4.1  PURPOSE 


The  purpose  of  this  section  is  to  analyze  the  critical  contexts  within 
which  considerations  of  accuracy  are  relevant.  In  each  such  context,  the 
intent  is  to  identify  both  where  considerations  of  accuracy  have  been 
analyzed  and  where  further  analysis  is  required. 


4.2  DATA 


4,2.1  Accuracy  of  Source  Analog  Data 
4. 2. 1.1  Charts 

The  accuracy  of  data  portrayed  on  man-made  navigational  charts  and 
maps  is  clearly  suspect  in  many  instances.  Charts  become  distorted  be¬ 
cause  of  shrinkage  and  expansion,  and  the  distortion  is  clearly  a  highly 
complex  non-linear  phenomena  from  a  mathematical  point  of  view.  The 
algorithm  of  registration  do~s  little,  if  anything,  constructive  to 
compensate  for  this  distortion  as  registration  is  represented  within  the 
classical  linear  model  of  maximum  likelihood  which  assumes  uniform 
stretching  or  shrinking  in  an  arbitrary  direction. 

When  such  charts  are  digitized  and  converted  to  geographic  coordinates, 
information  becomes  available  to  the  data  base  which  seriously  threatens 
its  integrity.  Thus,  the  ability  to  edit  the  data  base  becomes  of  para¬ 
mount  importance.  A  serious  look  should  be  taken  at  providing  such  a 
capability,  if  the  BDRS  system  is  to  be  used  as  a  true  data  base  system 
rather  than  a  librarian  as  it  was  originally  designed  to  be. 

The  accuracy  of  data  portrayed  on  charts  produced  mechanically  by 
plotters  on  such  systems  as  the  Lineal  Input  System,  presents  smother 
problem  as  the  material  out  of  which  the  charts  are  made  is  much  more 
resistant  to  distortion.  These  problems  will  be  discussed  momentarily  1 

in  Section  4.3  of  this  document.  j 
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4. 2. 1.2  Fathograms 


The  accuracy  of  fathogram  data  is  of  a  highly  questionable  nature. 

The  navigational  data  listed  in  the  ship’s  log,  especially  the  speeds  and 
courses,  have  been  proven  inaccurate  in  many  instances.  In  fact,  in 
some  cases  if  the  given  course  was  actually  followed,  the  end  position 
of  the  ship  would  be  in  a  completely  different  direction  than  where  its 
end  position  was  reported.  Therefore,  course  and  speed  adjustments  are 
often  necessary  when  the  actual  fathogram  processing  occurs. 

Besides  errors  in  the  log  navigational  data,  the  echogram  itself  may 
contain  inaccurate  data.  Many  times  the  paper  speed  of  the  fathogram 
seems  to  change  without  any  notification  being  given,  it  is  possible 
that  either  the  evaluator  who  checks  this  data  fails  to  correctly  scale 
and  mark  the  times,  or  the  person  in  charge  on  the  ship  forgets  to  mark 
the  time  and  later  guesses  its  position  on  the  fathogram.  In  any  case, 
the  times  must  be  properly  marked  on  the  echogram  and  the  digitizer  must 
in  some  way  be  notified  of  paper  speed  changes.  Otherwise,  this  inaccurate 
input  data  will  produce  unreliable  results. 


4. 2. 1.3  Data  Entry  of  Analog  Source  Materials 

Data  is  entered  by  the  user  within  the  digitization  subsystem  of  BDRS . 
When  graphical  feature  data  is  entered  with  a  cursor,  the  data  is  accepted 
as  is  by  the  system;  that  is,  there  is  no  error  term  employed  by  the 
software  to  smooth  out  the  errors  which  occur  in  data  entry  itself.  In  a 
linear  model,  the  typical  assumption  of  statisticians  is  that  such  error 
can  be  modeled  by  a  probability  distribution  with  a  zero  expectation  and 
a  variance  characteristic  of  the  particular  user.  Whether  the  inclusion 
of  such  an  error  term  would  be  fruitful  within  BDRS  itself  has  not  been 
analyzed  empirically. 

A  natural  question  to  ask  is  how  to  check  whether  the  data  entered 
by  the  user  is  representative  of  the  data  supplied  on  the  chart.  The  proof 
plot  provides  the  check  required.  If  the  proof  plot  is  a  perfect  overlay 
of  the  original  source  chart  as  it  is  taped  on  the  table  when  digitized, 
then  each  digitized  point  is  within  an  epsilon  of  its  correct  position. 

That  is,  depending  upon  the  resolution  of  the  data  when  digitized  (from 
1  mil  to  10  mils) ,  and  accuracy  of  the  plotting  device.  It  may  appear 
(to  the  human  eye)  that  two  chart  points  overlap  each  other,  but  in 
reality  may  actually  be  a  few  mils  apart. 

The  accuracy  of  the  sounding  data  entered  by  the  user  can  be  checked 
by  the  user  as  he  enters  the  sounding  value.  This  value  is  displayed  on 
the  Tektronix  4010  display.  If  the  user  is  employing  the  Threshold  500 
Voice  unit,  his  entry  is  further  displayed  on  the  Threshold  display  unit. 
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4.2.2  Accuracy  of  Processed  Data 
4. 2. 2.1  Registration 

The  algorithm  of  registration  is  thoroughly  discussed  in  Section 
2.2.2  of  this  document.  In  this  section  several  corollaries  pertaining 
to  the  problem  of  accuracy  will  be  deduced  from  the  mathematical  properties 
of  the  algorithm. 

It  was  noted  in  Section  2.2.4  of  this  document  that  registration 
points  should  be  picked  judiciously;  that  it  is  representative  of  the 
chart  as  a  whole  and  not  in  any  obvious  geometrical  pattern.  The  reason 
for  this  latter  condition  finds  its  justification  in  the  mathematical  fact 
that  an  earth  scale  meter  rectangle  of  arbitrary  vertices  can  result  from 
a  digitized  rectangle  with  acceptable  residuals.  For  example,  in  register¬ 
ing  a  UTM  chart,  if  the  vertices  of  a  rectangle  are  used  for  control  points 
and  the  user  enters  the  wrong  northings  and  eastings  for  the  points,  then 
if  his  incorrect  entries  also  constitute  the  vertices  of  a  rectangle,  the 
registration  algorithm  will  produce  a  mapping  which  has  acceptable  residuals 
Other  obvious  geometric  shapes  have  this  same  characteristic. 

A  second  property  of  the  algorithm,  which  is  actually  quite  unfortunate 
is  that  a  seriously  distorted  chart  may  be  registered  with  acceptable 
residuals.  Thus,  it  is  the  users  responsibility  to  ensure  that  he  is  not 
allowing  poor  data  into  the  BDRS  system.  There  is  a  check  which  can  be 
employed  for  this  case.  It  is  discussed  in  Section  4. 2. 2. 2  of  this 
document . 

A  final  corollary  of  this  algorithm  is  that  the  proper  registration  of 
a  good  source  chart  generates  an  extremely  accurate  mapping  from  the 
coordinate  frame  of  the  table  to  the  earth  rectangular  frame  in  day  1 
registration.  The  simplicity  of  the  algorithm  conjoined  with  the  par¬ 
titioning  of  symmetric  matrices  to  find  inverses  results  in  a  very  accurate 
mapping . 

4. 2. 2. 2  Coordinate  Transformations 

When  geographic  coordinates  are  mapped  to  the  earth  scale  meter  frame 
and  then  back  to  the  geographic  frame,  the  resultant  geographic  coordinates 
are  within  a  second  of  arc  of  the  original  geographic  coordinates.  The 
case  of  iterating  this  procedure  to  check  for  an  accumulation  of  harmful 
error  has  not  been  checked  rigorously. 
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Since  the  coordinate  transformations  and  the  registration  trans¬ 
formation  are  so  accurate,  the  following  sequence  constitutes  an  excellent 
test  of  whether  the  source  analog  chart  is  distorted  badly. 

J  Register  the  chart  and  build  a  table  file; 

J  Convert  table  file  to  geographic  file; 

^  Convert  geographic  file  to  table  file;  and 

J  Plot  table  file. 

If  the  plot  overlays  cleanly  with  the  source  data,  then  the  chart  is 
in  good  condition.  Otherwise,  the  accuracy  of  the  chart  is  seriously 
suspect . 


4. 2. 2. 3  Fathogram  Processing 

As  stated  in  Section  4. 2. 1.2,  the  accuracy  of  the  log  navigational 
data  is  in  many  instances  questionable.  Therefore,  much  track  adjusting 
occurs  with  regards  to  courses  and  speeds.  The  mathematical  algorithms 
used  for  these  calculations  are  discussed  thoroughly  in  Section  2.5.  It 
should  be  stressed  here,  however,  that  the  accuracy  of  the  fathogram 
processing  output  is  directly  related  to  the  accuracy  of  the  input. 
Consequently,  even  though  very  precise  mathematical  algorithms  are  em¬ 
ployed,  the  output  will  be  precisely  calculated,  but  incorrect,  if  the 
input  is  inaccurate.  For  good  results  good  data  is  imperative.  If  the 
differences  between  given  courses  and  speeds  and  adjusted  courses  and 
speeds  are  large,  then  the  input  data  should  be  thoroughly  questioned. 

In  turn,  the  output  file  should  probably  be  disregarded. 

Also,  if  paper  speed  changes  are  not  noted  on  the  fathogram  and, 
therefore,  not  taken  into  account  during  the  processing,  the  geographic 
values  will  not  be  correct  even  though  correct  depth  values  are  calculated. 
Thus,  if  a  change  in  paper  speed  occurs,  a  new  file  must  be  produced  with 
the  same  document  number  and  a  new  sheet  number.  This  will  result  in  the 
computation  of  a  new  time  scale  and  correct  correlation  of  depth  values 
to  the  latitude,  longitude  points.  As  can  be  seen,  the  user  must  somehow 
be  aware  of  paper  speed  changes.  Only  accurate,  well  marked  fathograms 
and  accurate  corresponding  navigational  data  will  assure  reliable  results. 
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4.3  PROBLEM  OF  VALIDATION 


In  order  to  evaluate  the  accuracy  of  the  map  projections,  charts  must 
be  utilized  which  represent  data  to  the  degree  of  accuracy  being  tested. 

The  Hydrographic/Topographic  Center  has  provided  such  a  chart  for  the 
Mercator  projection  test.  Charts  of  such  high  caliber  were  also  provided 
for  each  mapping  demanded. 

To  evaluate  the  accuracy  of  the  polygon  search  algorithm,  a  high  pre¬ 
cision  Gnomic  projection  chart  is  required.  The  great  circle  vertices  of 
the  polygon  will  map  to  straight  lines  on  such  a  chart.  Thus,  one  may  con¬ 
struct  with  precision  arbitrary  earth  polygonal  regions  on  the  chart  and 
test  arbitrary  points  for  inclusion  within  the  defined  chart  polygonal 
region . 

If  the  accuracy  of  the  map  projections  is  precisely  known,  the 
accuracy  of  the  functions  constructed  in  registration  can  be  tested  by 
simply  comparing  their  output  with  the  known  output  of  geographic  points 
either  identical  to  or  different  from  the  registration  points. 

The  overall  problem  of  all  of  these  validation  procedures  is  that 
they  demand  charts  which  are  'known*  to  be  accurate  within  the  degree 
of  precision  for  which  a  test  is  to  be  made.  If  the  charts  are  machine 
produced  from  the  Lineal  Input  System  (LIS) ,  then  the  projections  must 
conform  to  those  employed  in  LIS  itself.  Whether  this  is  desirable  or 
not  has  not  been  rigorously  analyzed  within  the  BDRS  research. 
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SECTION  5.  SYSTEM  CONFIGURATION 


5.1  PURPOSE 


The  basic  objective  of  this  section  is  to  review  the  overall  BDRS 
system  configuration  in  terms  of  both  its  hardware  and  software  architectures 
Additionally,  special  attention  will  be  paid  to  key  technical  areas  such  as 
data  base  structure,  file  and  record  formats,  etc. 

5.2  HARDWARE  CONFIGURATION 


Figure  5-1  depicts  BDRS  hardware  configuration,  consisting  of  the 
following: 

/  Data  General  ECLIPSE  C300  Processor  -  128K  core  memory 
/  Data  General  Magnetic  Tape  Units,  9  Track  (2) 

/  Data  General  6012  CRT 
/  Centronics  Line  Printer 

/  Data  General,  92MB  Disk  Drive,  dual  portable 
/  Data  Automation  Digitizing  Tables  (2) 

/  Tektronix  Graphic  Terminal,  4010,  (2) 

/  Data  General  6052  CRT 
/  Tektronix  4014  Graphic  Terminal 
Station  One  (Figure  5-2) 

J  42"  X  60"  active  Area  Data  Automation  (X/Y  Digitizer  Table) 

/  Standard  Cursor  (five  push  buttons) 
i /  Tektronix  4010  CRT 
/  16  Key  Keyboard 


GENERAL  6052  TEK  4014 


SERIAL  I  SIT  OATA  9100  IAUO 


Figure  5-2.  Station 


Station  Two  (Figure  5-3) 

/  42"  X  60"  active  area  Data  Automation  (X/Y  Digitizer  Table) 

/  Special  Cursor  (LED  display/five  push  buttons) 

/  Tektronix  4010  CRT 

/  Threshold  Technology,  Inc.,  -  Model  500  voice  data  entry  terminal 
/  16  Key  Keyboard 


5.3  BDRS  SOFTWARE  CONFIGURATION 


5.3.1  Software  Description 

The  software  developed  for  the  BDRS  provides  the  capability  for 
supporting  the  acquisition,  maintenance  and  exploitation  of  bathymetric/ 
hydrographic  data  pertinent  to  the  goals  and  objectives  of  the  Scientific 
Data  Department  (SD)  of  DMAHTC.  The  design  concept  employed,  allows  for 
the  integration  of  the  BDRS  to  existing  and/or  planned  systems  within  the 
DMAHTC  structure  for  the  purpose  of  contributing  to  the  overall  operational/ 
production  requirements  of  DMA  at  the  Hydrographic/Topographic  Center. 

DMAHTC' s  Bathymetric  Data  Library  (BDL)  operational  requirements  defined 
a  need  to  convert  data  from  its  graphic  analog  form  (i.e.,  charts,  smooth 
sheets,  fathograms,  etc.)  to  a  digitial  one,  capable  of  being  exploited 
for  the  purpose  of  supporting  the  BDL  operational  objective.  Additionally, 
a  capability  which  would  allow  for  the  storage  and  retrieval  of  the  digital 
data  in  a  geographic  format,  was  identified  as  being  necessary  if  the  BDL 
is  to  become  and  remain  responsive  to  its  role  of  supporting  chart/product 
generation . 

To  accomplish  these  goals,  the  BDRS  was  configured  with  the  software 
falling  into  three  functionally  oriented  subsystems;  Digitization,  Batch, 
and  Data  Base. 


5. 3. 1.1  Key  Areas 

To  achieve  the  functional  objectives  of  the  BDRS,  two  different 
operating  systems  were  required.  The  first  operating  system;  "BDRSSYS1", 
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was  developed  to  support  the  running  of  both  digitizing  tables  in  the  fore¬ 
ground  and  any  other  function  in  the  background. 

The  second  operating  system,  "BDRSSYS2" ,  was  developed  to  allow  the 
voice  digitizing  process  to  be  executed  in  either  ground  of  the  system. 

This  leaves  one  ground  available  for  other  BDRS  functions  to  be  executed. 

In  addition  to  developing  tailored  operating  systems,  foreground/back¬ 
ground  processing,  multi-tasking  and  overlays  were  utilized  in  developing 
the  BDRS. 

5. 3. 1.1.1  Foreground/Background  Processing 

The  BDRS  operates  in  a  foreground/background  mode.  This  permits 
unrelated  tasks  to  be  executed  sharing  the  basic  system  resources.  The 
process  makes  it  appear  that  the  tasks  are  being  executed  simultaneously. 
Figure  5-4  depicts  the  combinations  of  processes  that  could  be  run  on  the 
BDRS  using  the  dual  ground  processing  approach. 

5. 3.1. 1.2  Multi-Tasking 

The  following  is  a  detailed  discussion  concerning  the  Multi-Tasking 
convention  of  Data  General's  RDOS/FORTRAN .  It  has  been  used  extensively 
by  both  the  BDRS  Digitization  and  ON-Line  Data  Base  processes  and  for 
that  reason  should  be  closely  reviewed. 

/  Multi-Tasking 

A  task  is  a  logically  complete  unit  of  program  execution  that  requires 
system  resources  such  as  memory  and  CPU  control.  A  program,  the 
current  executable  contents  of  a  user  address  space,  contains  the 
code  paths  or  sequences  of  instructions  that  tasks  execute. 

Single- tasking  operation  is  relatively  simple,  involving  a  single  flow 
of  control  through  a  program,  no  matter  how  complex  the  branching 
structure  of  that  program  may  be  (Figure  5-5) .  Multitasking  consists 
of  multiple,  concurrent  flows  through  a  program,  where  the  various 
flows  (tasks)  compete  for  CPU  control  (Figure  5-6) . 

In  multitasking,  a  single  program  deals  easily  and  efficiently  with 
two  or  more  tasks  at  one  time.  Although  there  is  only  one  CPU,  and 
in  reality,  only  one  instruction  executes  at  a  time,  it  appears  as 
though  several  instructions  from  different  tasks  are  executing  simul¬ 
taneously.  This  is  because  tasks  take  turns  executing.  For  example, 
when  one  suspends  execution  (because  of  I/O  or  some  other  reason) , 
another  task  takes  over  control.  All  of  this  happens  automatically 
within  the  operating  system  and  is  invisible  to  the  user.  Thus,  you 
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Figure  5-4.  Examples  of  the  BDRS  Systems  Utilization  of 
Foreground  Background  Processing 
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Figure  5-5.  Single-Task  Program 
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Figure  5-6.  Multitask  Program 


have  no  need  to  keep  track  of  tne  various  tasks  and  to  appropriately 
switch  control  among  them.  Multitasking  takes  care  of  this  for  you 
and  at  the  same  time  handles  the  environment  more  efficiently.  While 
one  or  more  tasks  await  completion  of  their  I/O  operations,  other 
tasks  use  the  time  thus  made  available  to  do  their  computations.  As 
many  as  255  tasks  may  be  active  at  the  same  time. 

With  multitasking,  you  may  exercise  a  fine  control  over  the  tasks 
which  the  system  selects  for  execution  and  the  time  at  which  it  selects 
them.  When  you  define  a  task  and  specify  the  instructions  it  will 
execute,  you  also  assign  the  task  a  priority  relative  to  other  tasks. 
However,  you  may  change  task  priorities  during  program  execution. 

This  allows  you  to  control  which  tasks  receive  CPU  control  and  when. 

A  task  scheduler  allocates  CPU  control  to  the  highest  priority  task 
that  is  ready  either  to  perform  or  to  continue  to  perform  its  function. 

Although  each  task  in  a  multitask  environment  may  execute  independently, 
a  certain  amount  of  interaction  between  the  tasks  is  often  required. 
DGC's  multitasking  allows  you  to  communicate  between  tasks  conveniently, 
providing  for  synchronization.  For  example,  a  task  may  suspend  its 
own  execution  at  a  certain  point,  awaiting  a  signal  from  another  task. 

In  certain  situations,  it  is  appropriate  for  two  or  more  tasks  to 
execute  exactly  the  same  sequence (s)  of  instructions  yet  still  remain 
independent  of  one  another  and  use  their  own  sets  of  data.  In  such 
cases,  it  is  more  efficient  for  all  of  the  tasks  to  share  a  single 
set  of  instructions  than  to  duplicate  the  code  several  times.  This 
sharing  is  possible  provided  that  the  code  does  not  modify  itself, 
and  that  FORTRAN  sets  aside  a  separate  data  space  for  each  task. 

To  provide  this  separate  space  for  each  task,  FORTRAN  allocates  a 
part  of  the  runtime  stack  for  variables  which  the  task  uses.  Thus, 
it  separates  the  unmodified,  shared  code  from  the  modified  data  areas. 

We  call  the  shared  code  re-entrant  code  since  various  tasks  are 
entering  and  using  the  code  at  the  same  time. 

The  actual  sequence  of  events  in  the  use  of  re-entrant  code  is  as 
follows.  Each  time  you  initiate  a  task  in  a  multitasking  program, 
FORTRAN  assigns  the  task  a  task  control  block  and  a  piece  of  the 
runtime  stack.  The  task  control  block  keeps  track  of  which  instructions 
the  task  is  executing  and  the  data  space  allocated  to  the  task.  Two 
or  more  tasks  execute  a  single  subroutine  (re-entrant  code)  at  one 
time,  although  the  tasks  are  not  executing  the  same  statement  at  a 
given  instant.  Figure  5-7  illustrates  the  status  of  the  program 
at  one  point  in  time.  It  is  not  a  dynamic  picture  of  these  operations. 
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Task  Control  Block  and  Use  of 
Re-entrant  Code 
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In  many  cases,  an  applications  program  is  too  large  to  reside  in  main 
memory  at  one  time.  If  you  have  written  your  program  in  modules  (for  example, 
using  subroutines  or  functions) ,  you  may  use  the  overlaying  technique  to 
overcome  this  size  difficulty.  An  overlay  is  a  reserved  area  in  main  memory 
which  various  program  parts  or  modules  can  share. 

The  program  parts  (subroutines,  functions,  etc.)  reside  in  secondary 
storage  (on  disk)  until  needed  by  the  program.  Whenever  the  program  requires 
a  given  subroutine,  you  must  load  it  from  the  secondary  storage  area  into 
the  overlay  area  and  execute  it.  (Some  Data  General  operating  systems 
load  subroutines  automatically  when  you  call  them.)  While  a  given  subroutine 
is  in  the  overlay  area,  the  other  subroutines  not  in  use  remain  in  secondary 
storage  (on  disk) . 

The  size  of  the  overlay  area  you  reserve  in  main  memory  should  be  large 
enough  to  accommodate  the  largest  subroutine  or  function  that  you  intend  to 
call.  You  may  have  more  than  one  overlay  area  for  a  single  program,  and 
within  each  overlay  area,  you  may  have  as  many  as  256  overlays.  Therefore, 
you  may  have  a  much  larger  program  than  main  memory  can  ordinarily  accommo¬ 
date,  provided  that  you  write  it  in  modules. 

Let  us  assume  that  you  are  using  FORTRAN  on  an  RDOS  system  and  you 
load  the  main  program  with  subprograms  1  and  4  to  reside  in  main  memory 
and  subprograms  2  and  3  to  be  used  as  overlays.  Figure  5-8  indicates  the 
positions  of  the  various  program  parts  at  a  given  moment  after  loading 
and  before  executing  the  program. 

This  technique  of  overlaying,  is  used  extensively  throughout  the  entire 
BDRS  system.  Care  should  be  taken  to  fully  understand  this  technique 
and  how  it  was  utilized  within  the  BDRS  software  architecture,  so  that 
future  activity  relative  to  the  maintenance  of  existing  software  packages 
will  be  relatively  straight-forward  in  nature. 


5.3.2  Digitizing  Software 

Sources  of  input  into  the  BDRS  are  in  graphic  analog  form.  These 
sources  include  fathograms,  charts,  random  and  survey  track  data,  foreign 
source  data,  smooth  sheets  and  others.  The  digitizing  process  is  designed 
to  produce  digital  data  from  these  sources  using  state-of-the-art  hardware 
and  software  technology. 

The  digitizing  software  is  structured  modular ly.  Each  module 
represents  an  overlay  which  performs  a  separate  function  in  the  digitizing 


Figure  5-8.  Overlays 


process.  This  architecture  is  shown  in  Figure  5-9.  The  Master  Mode 
module  is  the  main  element  in  the  overall  software.  Each  of  the  five 
digitizing  functions  are  accessed  using  the  cursor  push  buttons  when 
in  Master  Mode.  This  type  of  approach  allows  for  additional  functions 
to  be  added  at  a  later  time  without  major  modifications  to  existing 
software . 

The  output  of  the  digitization  process  is  a  collection  of  table 
files  which  represent  the  analog  data  in  a  digital  form.  Throughout 
the  process  the  user  has  a  number  of  different  options  available  for 
entering  data.  The  options  include  the  "voice  box",  the  cursor,  and 
the  keyboard.  Visual  feedback  during  the  process  allows  maximum  control 
to  create,  and  edit  new  and  existing  files.  The  relationship  of  input 
to  output  in  the  digitizing  process  is  given  in  Figure  5-10. 

5.3.3  Batch  Software 


The  Batch  processes  provide  the  interfacing  of  the  digitizing  sub¬ 
system  to  the  data  base.  Batch  functions  were  designed  with  the  simpliest 
of  architectures.  Each  function  is  a  stand-alone  operation  using  no 
overlays.  To  reduce  the  complexity  of  each  function,  unique  operations 
were  divided  into  subroutines.  Figure  5-11  shows  the  separate  functions 
and  the  input/output  of  each. 

5.3.4  Data  Base  Software 


The  data  base  software  supports  the  capability  to  store,  retrieve, 
and  maintain  geographical  bathymetric  data.  It  also  provides  interactive 
access  as  well  as  conventional  batch  access.  In  order  to  build  such  a 
capability,  the  Data  Base  Subsystem  was  divided  into  three  unique  pro¬ 
cesses;  On-Line,  Batch,  and  Master  Mode.  The  architecture  used  to  imple¬ 
ment  these  processes  varies  depending  on  the  mode  of  operation. 

5. 3. 4.1  On-Line  Data  Base 

The  architecture  employed  in  designing  this  capability  makes  use 
of  the  multi-tasking  and  overlaying  techniques  described  earlier.  The 
multi-tasking  was  used  to  support  two  terminals  concurrently.  The  6052 
CRT  is  used  to  create  and  edit  document  and  source  description  records. 
Additional  functions  allow  a  user  to  geographically  locate  a  point  and 
change  the  depth  or  location  or  both.  The  second  terminal  is  the 
Tektronix  4014  graphic  CRT  which  supports  on-line  sectioning  of  the 


"•PWWpppp 


Figure  5-9.  Digitization  Functional  Architecture 
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VOICE  ENTRY 


Figure  5-10.  Digitization  Input  and  Output 
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data  base.  Each  overlay  represents  either  a  group  of  utility  subroutines 
or  a  specific  function  of  the  on-line  processes. 


5. 3. 4. 2  Batch  Data  Base 

The  architecture  behind  the  batch  software  is  not  as  complex  as  the 
on-line  software.  This  mode  of  operation  uses  a  single  task  with  four 
overlays.  Each  overlay  performs  a  separate  function  of  either  input, 
output,  or  logical  deletion  of  data  in  the  data  base. 


5. 3.4. 3  Data  Base  Master  Mode 

Master  Mode  software  allows  the  user  to  control  the  operational 
environment  of  the  data  base.  Physical  deletion  of  a  file  as  well  as 
user  access  is  controlled  under  this  mode  of  operation.  The  architecture 
is  comprised  of  a  single  task  using  six  overlays.  Each  function  defined 
by  its  separate  overlay  is  loaded  from  disk  when  called  by  the  Executive 
routine. 


5.3.5  Files  and  Record  Formats 


All  three  subsystems  of  the  BDRS  produce,  and  process  files.  The 
digitizing  process  produces  four  unique  table  files;  header,  index,  data, 
and  fathogram  (when  a  fathogram  is  digitized) .  Batch  processes 
produces  table  and  geographic  files.  The  Data  Base  creates  and  uses 
geographic  files.  The  location  of  these  files  in  relation  to  each 
subsystem  is  depicted  in  Figure  5-12. 

In  addition  to  files,  there  exists  document  and  source  description 
records  which  are  essential  to  the  data  base.  The  document  and  source 
description  record  is  used  to  describe  each  document  that  is  loaded  into 
the  data  base.  For  every  document  there  can  only  be  one  document 
description  record.  The  source  description  record  gives  more  information 
about  the  file  that  has  been  digitized.  There  can  be  more  than  one  source 
description  record  for  a  document. 

The  structure,  contents,  and  further  discussion  of  the  files  and 
records  can  be  found  in  Appendix  C  of  this  document. 


Figure  5-12.  File  Map 
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5.3.6  Data  Base  Structure 


The  structure  of  the  BDRS  data  base,  as  illustrated  in  Figure  5-13, 
consists  of  two  distinct  INFOS  files,  the  Index  file  and  the  Data  Base 
file.  As  illustrated,  the  Index  file  contains  five  levels  of  indexes, 
each  of  which  performs  the  following  function: 

/  Index  Level  0 

The  purpose  of  this  index  is  to  provide  the  data  base  user  the  capa¬ 
bility  to  access  the  BDRS  data  base  file  via  one  of  three  distinct 
entry  paths,  GEOgraphics,  USER  ID,  or  Document  number.  In  actuality 
this  is,  to  use  INFOS  terminology,  a  "dummy  index  level"  used  as  an 
alternative  to  the  method  of  establishing  three  separate  Index  files 
to  achieve  the  same  end  result.  Without  the  use  of  such  a  "Dummy" 
index  level,  the  overhead  associated  with  maintaining  three  separate 
index  files  in  core  could  become  overbearing  and  would  definitely 
lead  to  the  degradation  of  system  response  times. 

/  Index  Level  1 

Index  Level  1  consists  of  three  separate  INFOS  "tree  structures", 
each  of  which  is  accessed  via  the  Level  0  dummy  index.  The  Geographic 
tree  structure,  as  shown  in  Figure  5-13,  represent  the  scheme  for 
geographically  segmenting  the  earths  surface.  Each  low  level  segment, 
or  cell,  represents  a  fixed  geographic  area  and  points  to:  1)  a  record 
in  the  data  base  file  containing  qualitative/quantitative  information 
about  that  cell,  and  2)  Index  Level  2  tree  structure  containing  a 
document  entry  for  each  document  containing  coverage  for  that  area. 

The  document  number  tree  structure  of  Index  Level  1  contains  a  docu¬ 
ment  number  entry  for  each  document  currently  stored  in  the  data  base 
file.  Each  low  level  entry  in  the  tree  structure  points  to  1)  a  record 
in  the  data  base  file  describing  the  document,  and  2)  a  tree  structure 
in  Index  Level  2  of  all  Source  description  records  associated  with 
a  particular  document. 

/  Index  Level  2 

Index  Level  2  also  has  three  tree  structures  associated  with  it.  For 
the  GEO  tree  structures  of  Index  Level  1,  a  tree  structure  is  main¬ 
tained  in  Index  Level  2  of  all  document  numbers  with  coverage  in 
each  of  the  basic  GEO  cells.  The  document  number  stored  in  this 
index  tree  structure  will  be  used  by  the  BDRS  data  base  software  to 
access  the  actual  data  stored  in  the  data  base  file.  Access  will  be 
gained  via  the  document  number  index  as  shown  in  Figure  5-13.  The 
Index  Level  2  tree  structure  associated  with  the  document  number  index 
of  Level  1  is  used  to  carry  those  Source  ID  numbers,  each  of  which 
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Figure  5-13.  BDRS  Data  Base  Structure 
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represents  a  unique  source  description  record,  associated  with  each 
unique  document.  Each  low  level  entry  in  this  tree  structure  points 
to  1)  the  actual  source  description  record  in  the  data  base  file,  and 
2)  a  feature  classification  tree  structure,  for  each  source,  located 
within  Index  Level  3  of  the  document  number  index. 

•J  Index  Level  3 

This  index  level  has  but  one  tree  structure  associated  with  it,  and 
that  structure  called  feature  classification,  falls  within  the 
Document  index  path  to  the  data  base  file.  Its  purpose  is  to  provide 
a  further  breakdown  of  bathymetric  data  into  class  and  types.  As 
mentioned  earlier,  each  document  has  one  or  more  source  descriptor 
records  associated  with  it  and  each  source  may,  or  may  not,  have  one 
or  more  types  of  features  associated  with  it.  So  as  a  result.  Index 
Level  3  is  used  to  "breakout"  features  by  class  and  type,  all  of  which 
are  directly  related  to  a  source  entry  in  Index  level  2.  Each  entry 
in  the  Index  level  3  tree  structure  simply  points  to  an  Index  level 
4  tree  structure  which  contains  an  entry  for  every  feature  stored 
in  the  BDRS  data  base. 

J  Index  Level  4 

This  Index  level  represents  the  "ground  floor"  of  the  Index  file. 

It  is  at  this  level  that  an  entry  must  exist  for  each  record  stored 
in  the  data  base  file.  Each  feature  or  string  of  lat,  long,  and 
depth  values  is  represented  by  a  unique  segment  number  stored  in  a 
Level  4  tree  structure  with  respect  to  its  entry  in  the  feature 
classification  Index  level  3. 


SECTION  6,  CONCLUSIONS  AND  RECOMMENDATIONS 


6.1  GENERAL 


Synectics  Corporation  is  pleased  to  have  been  given  the  opportunity 
to  work  closely  with  Rome  Air  Development  Center  (RADC)  and  the  Defense 
Mapping  Agency  Hydrographic/Topographic  Center  (DMAHTC)  over  the  past 
36  months  in  the  phased  development  and  implementation  of  the  Bathymetric 
Data  Reduction  System  (BDRS) .  We  are  of  the  opinion  that  efforts  such  as 
this  demonstrate  the  feasibility  and  effectiveness  of  the  "team-concept" 
in  system  design,  development,  and  implementation:  that  is,  the  production 
centers  working  closely  with  the  research  laboratories  and  private  industry 
in  the  specification  and  development  of  state-of-the-art  based  automated 
systems  and  techniques,  in  support  of  DMA's  growing  production  requirements. 

Throughout  the  36  month  development  period,  the  goal  of  establishing 
a  cost-effective  system,  capable  of  demonstrating  its  functionality  and 
applicability  in  the  operational/production  environment  at  DMAHTC  was 
rigorously  pursued.  Additionally,  care  was  taken  to  include  in  the  software/ 
system  concept,  the  "hooks  and  handles"  deemed  necessary  to  support  future 
growth  and  system  adaptability/expandability.  The  strict  adherance  to  this 
approach  by  Synectics,  RADC,  and  DMAHTC,  resulted  in  the  development  of  a 
system  which  with  time  and  attention  could  play  a  much  greater  role  than 
was  originally  intended  in  support  of  DMAHTC' s  "soon-to-be-digital" 
operation. 

In  the  subsections  that  follow,  the  topics  of  hardware,  software,  and 
file  maintenance  will  be  discussed  relative  to  their  respective  limitations, 
whether  they  be  known  or  anticipated.  Additionally,  recommendations  will 
be  offered  that  will,  if  adopted,  vastly  enhance  the  existing  BDRS  capa¬ 
bility  by  either  eliminating  known  system  limitations  or  by  providing  new 
means  by  which  the  system  users  may  further  exploit  the  BDRS  resident 
digital  bathymetry.  Prior  to  continuing,  Synectics  would  like  to  clarify 
its  meaning  of  the  term  "limitations".  Its  use  is  in  no  way  meant  to  infer 
that  the  current  BDRS  system  is  not  responsive  to  those  system  requirements 
identified  in  the  SOW.  Those  limitations  that  will  be  discussed  relate 
primarily  to  the  current  hardware  configuration  and  its  inability  to  support 
an  expanded  BDRS  production  capability.  Such  hardware  limitations  sur¬ 
faced  early-on  in  the  effort  (Synectics  Technical  Proposal)  and  were 
agreed  upon  as  being  'givens'  if  a  cost-effective,  functionally  oriented 
system  development  was  to  be  achieved. 
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6.2  HARDWARE 


The  current  BDRS  hardware  configuration,  as  shown  in  Figure  6-1, 
adequately  supported  the  cost-effective  development  of  the  Digitization, 
Batch,  and  Data  Base  processes  of  the  BDRS.  However,  if  maximum  benefits 
are  to  be  realized  from  the  functional  processes  of  the  BDRS  once  the 
system  has  been  transitioned  into  a  production  support  role,  hardware 
upgrading  will  be  required.  This  process  will  not  require  the  "moth¬ 
balling"  of  existing  hardware  components.  Figure  6-2  graphically  depicts 
a  candidate  configuration  which  would  combine  existing  hardware  components 
with  newly  acquired  ones,  to  form  an  extremely  powerful  BDRS  configuration 
Such  a  configuration  would  support  extensive  growth  relative  to  digital 
data  base  exploitation.  The  rationale  used  in  defining  an  "advanced" 
configuration  was  based  primarily  on  the  following: 

J  Inability  of  certain  hardware  components  of  the  current  con¬ 
figuration  to  support  system  growth; 

^  The  need  to  separate  the  incompatible  processes  of  digitization 
and  data  base.  Any  attenpt  to  combine  a  high  priority  real¬ 
time  data  collection  process,  such  as  digitization,  with  a 
highly  interactive  I/O  bound  data  base  application,  will 
inevitably  result  in  the  inefficient  use  of  system  resources 
and  user  response  time  degradation;  and 

^  The  need  to  support,  in  a  timely  and  efficient  manner,  an 
anticipated  increase  in  user  demands  on  the  BDRS  data  base. 

In  the  paragraphs  that  follow,  specific  hardware  components  of  the 
current  configuration  will  be  discussed  with  regard  to:  1)  the  impact 
each  has  on  the  growth  of  the  current  system,  2)  what  role  each  com¬ 
ponent  will  play  in  the  advanced  configuration,  and  3)  what  additional 
components  of  similar  nature  will  be  required  to  assure  maximum  system 
expandability/flexibility. 

J  Disk  Storage 


Disk  storage  capacity  of  the  current  BDRS  system  is  92  mega¬ 
bytes.  This  is  more  than  adequate  to  support  the  processes  of 
digitization  and  batch,  but  falls  far  short  of  supporting  what 
is  anticipated  as  being  a  large,  ever  growing  bathymetric 
data  base.  Additionally,  under  the  current  configuration, 
the  92  MB  disk  is  supporting  all  system  activities,  resulting 
in  the  phenomena  known  as  "disk-thrashing".  That  is,  the 
uncontrollable  movement  of  the  read/write  heads  in  support 
of  totally  unrelated  activities.  Such  thrashing  results  in 
extremely  poor  utilization  of  system  resources  and  ultimately 
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CENTRONICS  PRINTER 


Figure  6-1.  BDRS  Hardware  Configuration 


Figure  6-2.  Enhanced  BDRS  Configuration 


limits  the  ability  of  the  system  to  be  responsive  in  a  timely 
and  efficient  manner  to  user  processes. 

A  means  of  alleviating  such  restraints  would  be  to,  as  illustrated 
in  Figure  6-2 ,  dedicate  the  92  MB  disk  to  the  digitization  and 
batch  processes  and,  on  a  separate  data  base  configuration, 
install  dual  277  MB  disks  to  provide  dedicated  storage  to  the 
BDRS  data  base.  Additionally,  a  small,  fast  fixed-head  disk 
could  be  used  as  a  system  disk,  supporting  only  operating  system 
and  application  software  storage.  The  data  base  storage  facility 
may  be  expanded  to  support  four  (4)  277  MB  disks  per  controller, 
with  a  two  controller,  8-pack  configuration  being  maximum. 

Line  Printer 

The  current  BDRS  Centronics  Line  Printer,  which  runs  at  a  maxi¬ 
mum  rate  of  100  LPM,  would  be  inadequate  in  its  support  of  a 
large,  report-oriented  data  base  system.  At  minimum,  a  300  LPM 
printer  should  be  dedicated  to  the  data  base  process,  with  the 
current  printer  being  relegated  to  the  digitization/batch  sub¬ 
system. 

Voice  Input 

Recent  breakthroughs  in  hardware  technology,  relative  to  Voic? 
Input,  have  lead  to  the  development  of  a  faster  Voice  Input 
device,  capable  of  handling  a  much  larger  vocabulary.  The 
current  voice  configuration  is  more  than  capable  of  supporting 
its  intended  role  and  could  be  field-upgraded  with  the  new  hard¬ 
ware  for  the  purpose  of  further  enhancing  its  applicability  to 
DMAHTC  as  a  viable  data  entry  tool. 

Memory 

Currently,  there  is  an  inadequate  amount  of  memory  (256  KB)  to 
support  more  than  two  on-line  data  base  users  at  a  given  time. 
Additional  factors  also  contribute  to  this  problem ,  primarily 
operating  system  limitations,  and  will  be  discussed  later  in 
the  section.  The  availability  of  free  or  uncommitted  memory, 
plays  a  major  role  in  whether  or  not  INFOS  can  be  responsive, 
in  a  timely  manner,  to  requests  for  data  resident  within  the 
data  base  structure.  The  more  free  memory  that  can  be  made 
available  to  INFOS,  the  better  your  data  base  related  response 
times  will  be.  The  reason  for  this  is  that  INFOS  makes  an 
attempt  to  maintain  in  memory  as  much  of  the  most  frequently 
used  data  and  index  information  as  it  can.  If  large  amounts 
of  free  memory  are  available,  INFOS  will  be  required  to  per¬ 
form  far  fewer  disk  accessed  in  attempting  to  satisfy  a  user 
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request  for  data.  Fewer  disk  accesses  translates  into  quicker 
response  times  for  the  users. 

The  advanced  configuration  addresses  this  problem  by  specifying 
one  million  bytes  of  memory,  or  4X  the  current  configuration.  This 
will,  in  conjunction  with  a  more  advanced  operating  system, 
benefit  DMAHTC  in  two  ways:  1)  INFOS  will  have  the  free  memory 
it  needs  to  operate  efficiently,  and  2)  there  will  be  memory 
available  to  support  the  development  of  new  applications  or  the 
addition  of  more  on-line  data  base  users. 

Hard-Copy  Device 

Currentlv,  no  "OUIK-LOOK"  capability  exists  by  which  the  user 
may  obtain  a  hardcopy  version  of  what  he  is  currently  viewing  on 
the  Graphic  CRT.  The  inclusion  of  such  a  capability  would 
eliminate  the  need  to  take  the  data  through  the  complete  "Proof 
Plot"  process  whenever  a  simple  hardcopy  is  required.  Such  a 
device  is  available  from  Tektronix  as  a  standard  off-the-shelf 
item. 

Spare  Parts 

The  issue  of  excessive  "dpwn-time"  due  to  hardware  failure  is 
a  critical  one  which  must  be  addressed  and  dealt  with  by  super¬ 
visory  DMAHTC  personnel.  Currently,  all  hardware  components 
of  the  BDRS  are  covered  under  maintenance  contract  with  Synectics 
Corporation;  who  in  turn  has  issued  sub-contracts  to  the 
appropriate  vendors  for  on-call  maintenance  of  their  components. 
Such  a  maintenance  contract,  whether  it  be  with  Synectics  or 
directly  with  the  hardware  firms,  should  be  considered  "mandatory", 
if  excessive  down-times  are  to  be  avoided  and  the  BDRS  is  to 
remain  a  viable  responsive  production  support  tool. 

In  addition,  DMAHTC  could  maintain  a  selection  of  spare  parts 
which  have,  over  time,  proven  to  be  more  susceptible  to  failure 
due  to  repeated  use.  Candidates  for  such  a  selection  could  be 
Data  Automation's  5-button  cursors  and  16  key  keyboards.  With 
such  spare  parts  on  hand,  failures  would  have  no  impact  on 
what  could  be  an  emergency  production  schedule. 

Communications  Controller 

Data  General  Corporation's  DCU-200  Communication  Controller  is 
capable  of  supporting  a  maximum  of  256  remote  synchronous/ 
asychronous  communication  lines.  It  is  fully  supported  by 
DG's  AOS  operating  system  and  communications  handling  software 
(CAM) .  Its  basic  function  is  to  relieve  the  main  processor 


of  the  burden  of  handling  each  and  every  interrupt  created 
by  a  key  strike  at  the  remote  terminal  devices.  It  will, 
unless  otherwise  advised,  accommodate  data  in  its  own  internal 
buffers  until  the  desired  number  of  characters  have  been 
assembled.  Once  this  is  done,  it  will  interrupt  the  main 
CPU  and  pass  the  data  on.  The  benefits  of  such  a  capability 
are  obvious  when  you  consider  the  potential  for  user  accesses. 


6.3  SOFTWARE 


The  current  BDRS  system  is  comprised  of  two  basic  categories  of  soft¬ 
ware,  operating  system,  and  applications.  The  operating  system  (RDOS) 
was  provided  by  Data  General  Corporation  with  the  hardware,  while  the 
applications  software  was  developed  by  Synectics  Corporation  during  the 
36  month  development  period.  In  the  subsections  that  follow,  sub-sets 
of  each  category  which  are  felt  to  be  limitations  of  the  system,  will  be 
discussed  relative  to  Lheir  respective  roles  in  the  current  BDRS. 
Additionally,  improvements  to  such  sub-sets  will  be  recommended  that  will, 
if  implemented,  greatly  enhance  the  overall  BDRS  system. 

6.3.1  Operating  System  (RDOS) 

The  present  BDRS  runs  under  the  control  of  Data  General's  RDOS 
(MRDOS)  Operating  System.  The  RDOS  architecture  is  based  on  a  foreground/ 
background  approach  to  multi-processing  which  strictly  limits  the  size 
of  each  process  to  the  32K  word  partition  size.  Such  a  limitation  con¬ 
tributes  to  the  current  systems  inability  to  support  more  than  two  (2) 
ON-line  data  base  users  from  within  a  single  ground  (32K  partition). 
Complex  multi-tasking  programming  techniques  must  be  used  if  a  single 
ground  is  to  be  used  to  run  more  than  one  process.  This  technique  was 
used  successfully  for  both  the  digitization  and  on-line  data  base  pro¬ 
cesses.  Additionally,  multi-tasking  mandates  the  use  of  the  RDOS  over¬ 
lay  facility.  This  is  done  at  the  expense  of  user  response  times  caused 
by  added  disk  accesses  or  "thrashing",  so  as  to  minimize  the  per-task 
consumption  of  memory  within  the  particular  ground  or  32K  partition. 

The  smaller  each  task,  the  more  tasks  that  can  be  run  concurrently  from 


within  a  single  ground.  However,  it  becomes  extremeiy  difficult  to  con¬ 
tinuously  fragment  complex  code  so  that  additional  users  may  be  supported 
from  within  a  single  ground.  At  some  point,  a  practical  maximum  is 
reached,  and  Synectics  is  of  the  opinion  that  such  a  maximum,  relative 
to  the  ON-line  data  base  process,  has  been  met  at  two  (2).  If  an  expanded 
BDRS  ON-line  data  base  capability  is  to  be  developed  in  the  future, 
Synectics  recommends  a  hardware  configuration  similar  to  the  one 
illustrated  in  Figure  6-2,  supported  by  an  AOS  type  operating  system. 
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AOS  is  a  Data  General  developed  operating  system  capable  of  supporting 
true  multi-processing.  It  supports  up  to  2  MB  of  memory,  which  is  8X 
that  of  the  current  BDRS .  Such  expandability  is  critical  to  the 
viability  and  responsive  growth  of  a  data  base  capability  such  as  the 
one  currently  implemented.  AOS  also  eliminates  the  need  to,  using 
advanced  programming  techniques,  "program-around"  the  limitations  of 
the  operating  system  relative  to  multi-processing.  Under  AOS  control, 
multi-user  processes  are  supported  as  a  standard  feature  of  the  operating 
system. 


6.3.2  Applications  Software 

Inasmuch  as  the  BDRS  has  demonstrated  its  ability  to  support,  in  a 
functional  sense,  DMAHTC's  bathymetric  data  reduction  process,  attention 
should  be  focused  on  ways  of  enhancing  and  refining  its  capabilities. 
Throughout  the  BDRS  development  period,  it  became  increasingly  obvious 
to  all,  that  a  number  of  application  areas  offered  far  greater  potential 
for  further  exploitation/development  than  had  been  originally  envisioned. 
It  also  became  evident  that  other  applications  would  require  refinements 
if  they  were  to  be  totally  effective  in  supporting  DMAHTC  production 
objectives. 

In  the  paragraphs  that  follow,  a  number  of  such  applications  will  be 
identified  and  discussed  with  regard  to  their  current  and  recommended 
capabilities . 

^  Plotting  Capabilities 

The  current  plot  packages  are  able  to  plot  data  represented  in 
BDRS  X,  Y  table  format.  This  limits  its  ability  to  plot  geo- 
sectioned  data  crossing  180°  of  longitude.  As  illustrated  in 
Figure  6-3,  a  geo-sectioned  file  crossing  the  international 
date  line  will  not  be  plotted  as  a  continuous  chart.  Instead, 
the  data  will  be  plotted  at  opposite  ends,  exactly  as  it  would 
be  found  on  an  X,Y  table. 

During  implementation  this  condition  was  never  brought  up  as  a 
capability.  However,  the  plot  packages  could  be  upgraded  to 
plot  such  cases  representing  data  as  it  would  be  viewed  on  the 
surface  of  the  earth.  To  do  this  it  would  be  necessary  to  check 
for  the  condition  in  the  conversion  from  geographies  to  table 
coordinates,  and  make  appropriate  adjustments.  This  enhancement 
would  reduce  the  size  and  present  a  more  meaningful  plot  of  the 
data. 


In  addition,  the  current  plot  routines,  except  GEBCO  TRACK  LINE, 
do  not  label  the  geographic  bounds  of  the  plot.  Plotting  the 
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geographic  bounds  and  intervals  would  be  a  useful  enhancement 
providing  the  user  with  a  quick  method  of  geographically 
referencing  the  data. 

Geographic  Retrievals 

On-line  retrievals  provide  expedient  accessing  of  geographic  data 
within  the  data  base.  However,  due  to  core  restrictions  relative 
to  internal  buffer  sizes,  this  process  is  limited  by  the  size 
of  the  geographic  area  that  can  be  retrieved  and  displayed.  The 
maximum  area  allowed  is  one  that  will  cover  no  more  than  150 
mapping  grid  cells.  This  corresponds  to  an  area  that  is  eight 
degrees  of  latitude  by  twelve  degrees  of  longitude.  If  an  area 
larger  than  this  is  retrieved  only  that  data  covering  the  above 
mentioned  area  will  be  displayed.  This  restriction,  however,  does 
not  exist  for  the  batch  geographic  sectioning  routines  which  has 
far  more  core  available  to  it  for  buffering.  This  condition  should 
be  upgraded  to  allow  the  retrievals  to  cover  any  geographic  area. 

Additional  improvements  should  be  made  to  further  exploit  the 
data  base.  Currently  the  BDRS  is  only  capable  of  displaying 
the  data  as  described  by  the  plot  packages  and  the  graphics  CRT. 

This  allows  the  data  to  be  viewed  as  one  dimension.  Some  additional 
capabilities  that  could  be  added  using  BDRS  geographic  data  are 
cross  sectional  displays  of  the  data  base,  bottom  contour  plots 
and  simulation  of  a  three  dimensional  model  of  the  ocean  floor. 

A  cross  sectional  retrieval  and  display,  in  theory,  would  allow 
the  user  to  enter  two  geographic  points  and  produce  a  single 
track  of  data.  This  track  could  then  be  displayed  as  a  cross 
section  of  the  ocean  floor.  Once  the  points  are  plotted,  a 
curve  fitting  algorithm  could  be  used  to  simulate  additional  depths. 
Figure  6-4  illustrates  a  sample  cross  sectional  display.  This 
capability  would,  in  effect,  simulate  a  fathogram  from  the  data 
base. 

Bottom  contour  charts  could  also  be  produced  using  the  current 
BDRS  geographic  formats.  Averaging  techniques  could  be  employed 
to  produce  a  display  as  shown  in  Figure  6-5.  Depths  within  a 
user  defined  range  would  be  grouped  together  to  form  a  bottom 
contour  and  displayed  as  such.  This  could  be  implemented  on  the 
Tektronix  Graphic  CRT  using  various  shading  patterns  to  represent 
the  different  depth  values.  Although  shading  patterns  represent 
one  way  of  representing  bottom  contours,  another  option  would 
be  to  upgrade  the  system  using  a  color  graphics  CRT.  Such  a 
capability  could  be  made  to  allow  the  user  to  define  what  colors 
would  represent  particular  depth  values.  Additional  options 
could  control  the  depth  ranges  to  make  the  bottom  contouring 
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as  fine  as  desired.  For  example,  a  rough  contour  would  include 
depths  of  100  to  200  feet.  The  user  may  wish  to  break  this  down 
into  contours  of  100  to  150,  and  150  to  200  feet.  This  would 
enable  high  and  low  points  to  be  flagged  within  the  area. 

BDRS  geographic  files  could  also  be  used  to  simulate  a  model  of 
the  ocean  floor  (Figure  6-6) .  The  location  of  a  depth  would  be 
calculated  in  relation  to  a  grid,  and  a  depth  value  would  be 
stored  for  a  particular  grid  cell.  The  depths  stored  for  the  grid 
would  then  be  used  to  calculate  additional  depths  filling  in 
the  remaining  grid  cells.  The  depths  from  the  grid  would  then  be 
converted  to  X,Y  locations  on  a  CRT  display,  creating  a  model  of 
the  ocean  floor.  Further  development  could  provide  capabilities 
to  rotate,  and  scale  the  model,  as  well  as  offering  isometric, 
dimetric  and  perspective  views  of  the  area. 

y/  Fathogram  Processing 

Although  Fathogram  Processing  is  presently  an  efficient  capability 
a  few  limitations  exist  that  could,  without  too  much  effort,  be 
eliminated. 

At  the  moment,  every  time  the  paper  speed  changes,  a  new  file 
with  the  same  document  number  but  a  different  sheet  number  must 
be  created.  This  has  no  effect  on  the  actual  fathogram  processing 
It  does,  however,  hamper  the  digitizing  process  since  it  becomes 
necessary  to  stop  digitizing,  close  the  current  file,  and  create 
a  new  one.  If  this  doesn't  have  to  be  repeated  often,  no  draw¬ 
back  really  exists.  But,  if  the  paper  speed  changes  are  frequent, 
this  method  becomes  cumbersome. 

A  suggested  solution  to  this  problem  is  to  incorporate  paper 
speed  change  data  into  fathogram  file  change  records  during  the 
digitization  process.  This  would  eliminate  the  need  to  create 
new  files  and  thus  make  fathogram  digitization  a  smoother  process. 

The  other  limitation  that  presently  exists  is  the  incapability  to 
calculate  geographic  positions  when  the  ship's  track  crosses  the 
equator.  It  is  now  necessary  to  produce  two  files.  One,  con¬ 
taining  track  segments  above  the  equator,  and  the  other  containing 
track  below.  A  simple  addition  can  be  made,  however,  to  obtain 
this  capability. 

/  Geographic  to  Table  Conversion 

The  geographic  to  table  conversion,  as  it  presently  exists,  pro¬ 
duces  an  extremely  accurate  and  useful  table  file.  However, 
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it  is  limited  in  one  respect.  It  cannot  be  immediately  edited. 
Only  original  table  files,  not  table  files  produced  from  a 
geographic  file  conversion,  can  be  edited.  Adding  this  one 
capability  would  greatly  enhance  the  geographic  to  table  con¬ 
version.  In  principle,  this  is  possible  to  implement  by  em¬ 
ploying  a  day  'n'  registration  on  the  resultant  table  file. 


This  can  be  seen  as  follows.  When  the  file  is  converted,  the 
registration  points  of  the  file  are  also  converted.  The  resul¬ 
tant  file  has  been  day  1  registered  in  the  sense  that  a  perfect 
fit  is  obtained  with  least  square  best  fit  coefficients  of  <J>. 
This  means  that  any  table  point  in  the  file  need  only  be  scaled 
to  earth  scale  meters  followed  by  a  translation  from  the  chart 
earth  scale  meter  lower  left  hand  corner  to  a  true  origin  to 
obtain  the  true  earth  scale  meter  value  of  the  table  point.  The 
plotted  chart,  when  placed  on  the  table,  is  registered  as  a  day 
'n*  registration  of  the  perfect  fit  file.  Therefore,  given 
that  a  set  of  registration  points  are  in  the  geographic  file,  an 
arbitrary  geographic  file  can  be  brought  to  table,  edited,  and 
reconverted  to  geographic  form. 


The  mathematical  simulation  of  this  is  as  follows.  Suppose  (<j>,A) 
are  the  latitude  and  longitude  of  an  arbitrary  coordinate  in  the 
geographic  file.  Let  XL,YL  be  the  map  scale  meter  value  of  the 
lower  left  hand  corner  of  the  chart.  Let  X^,  be  the  map  scale 

meter  value  of  the  coordinate  (<f) , X)  .  The  table  X,Y  of  the  point 
is 


(1)  X  =  t(X^-XL)  +  3  inches]  .  conversion  to  mils 

(2)  Y  =  [(Y^-Y^  +  3  inches]  .  conversion  to  mils 

Let  Xn,Yn  be  the  map  point  X,Y  (<j>,A)  when  the  map  is  placed  on 
the  table  which  is  produced  by  a  plot  of  the  table  file.  Then 
registration  will  map  XnYn  to  X,Y  and  X^fY^  need  only  be  cal¬ 
culated  from  equations  1  and  2  to  give  the  map  scale  meter  values 
of  ( 0 , X) .  when  scaled  to  earth  scale  meters  by  multiplying  by 
the  map  scale,  the  earth  scale  meter  value  is  obtained  for  ( 0 , X ) . 


6.4  FILE  MAINTENANCE 


An  efficient,  accurate,  and  meaningful  method  of  maintaining  files 
is  of  utmost  importance  if  the  full  capability  of  BDRS  is  to  be  realized. 
In  a  very  short  time  a  large  number  of  files  can  be  created  and,  unless 
they  are  properly  maintained,  total  confusion  will  occur.  An  organized 
system  must  be  designed  to  keep  track  of  the  files'  contents,  creators, 
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dates  of  creation,  etc.  Also,  a  magnetic  tape  backup  of  all  files 
should  be  produced  on  a  regular  basis.  Although  it  is  up  to  the  user 
to  develop  a  file  maintenance  system  inherent  to  his/her  own  needs, 
some  suggestions  on  how  this  necessary  task  can  be  accomplished  follow. 

Much  information  about  the  file  can  be  stated  in  the  filename  (Job 
ID)  created  when  a  file  is  digitized.  For  example,  the  eight  character 
filename  can  be  used  to  designate  when  the  file  was  created,  by  whom, 
and  what  it  contains.  Four  characters  can  be  used  to  store  the  date  the 
file  was  digitized  (two  for  the  month,  two  for  the  year) .  Two  other 
characters  can  be  the  user's  initials  or  special  ID.  The  last  two 
characters  can  represent  a  code  indicating  certain  characteristics  of, 
or  source  of  the  file's  contents.  An  example  filename  would  appear  as 
"0180PB24",  where  01  represents  the  month,  80  represents  the  year,  PB 
is  the  user's  initials,  and  24  is  a  file  content  or  source  code.  A 
written  log  should  also  be  maintained  daily  in  which  any  new  "Job  ID" 
and  its  description  is  recorded. 

The  importance  of  making  sure  that  all  files  are  saved  on  backup 
tape  must  be  stressed.  A  good  rule  to  follow  is  to  save  each  day's 
work  to  tape.  Also,  on  the  first  of  every  month  a  backup  tape  of  the 
last  month’s  work  could  be  produced.  If  the  above  mentioned  filenaming 
convention  is  used,  dumping  the  month's  files  to  tape  would  be  an  easy 
process.  For  example,  one  simple  command  to  dump  to  tape  all  files  with 
0180  in  them  would  save  all  table  files  including  the  data,  header,  index, 
and  fathogram  files  created  during  the  entire  month  of  January  1980. 
Possibly,  after  saving  the  month's  table  files  to  tape,  they  could  then 
be  deleted  leaving  plenty  of  room  on  the  disk  for  new  files  to  be 
created . 

Another  important  aspect  of  file  maintenance  is  to  keep  track  of  what 
happens  to  a  table  file  once  it  is  created.  The  line  printer  summary 
sheets  of  each  BDRS  run  should  be  kept  together  in  an  orderly  manner  for 
each  "Job  ID".  This  way,  no  matter  what  BDRS  function  the  file  is  pro¬ 
cessed  through,  a  complete  record  of  its  history  is  available  on  the 
summary  print  outs. 

The  above  suggestions  are  just  a  few  ways  in  which  file  maintenance 
can  be  accomplished.  The  user  can  devise  his/her  own  system  if  desired. 
However,  the  importance  of  a  standard  file  maintenance  system  from  the 
inception  of  BDRS  is  imperative  for  success. 
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GLOSSARY 


AUXILIARY  FUNCTIONS  —  These  functions  allow  the  user  to  enter  or  change 

digitizing  parameters.  To  display  these  functions,  the  user  must 
be  digitizing  and  be  in  "Master  Mode."  Keying  in  an  "A(CR)"  at  the 
console  will  display  the  auxiliary  functions. 

BACKGROUND  TERMINAL  FOR  BDRS  —  The  main  console  from  which  all  BDRS  functions 
are  initiated. 

BASE  ELEVATION  —  The  starting  elevation  when  digitizing  a  bottom  contour. 

The  user  will  be  asked  to  enter  the  value  if  "Bottom  Contour"  was 
selected  during  header  selection.  User  may  alter  this  elevation 
in  Master  Mode  by  hitting  "I(CR)"  or  "D(CR)”  which  will  increment 
or  decrement  the  elevation  respectively  by  the  contour  interval. 

The  elevation  can  also  be  changed  using  Auxiliary  Functions. 

BASE  LATITUDE  —  The  latitude  where  the  chart  or  map  is  most  accurate. 

BOTTOM  LATITUDE  —  The  bottom  (lowest)  latitude  of  the  area  being  digitized. 

CENTRAL  MERIDIAN  —  The  center  or  mid  longitude  value  of  the  area  being 
digitized. 

CHART  LEFT  LONGITUDE  —  The  left  longitude  of  the  map  or  chart  being  used. 

CHART/MAP  SCALE  —  The  ratio  between  the  linear  dimensions  of  a  map  or  chart 
and  the  actual  dimensions  represented. 

CLASS  MASK  —  The  first  two  numbers  of  the  feature  class  codes.  It  is  used 
during  the  digitizing  function. 

COMMENT  BLOCK  —  A  64-word  block  used  to  store  ASCII  enaracters  input  by  the 
user  in  the  Master  Mode  Auxiliary  Functions.  T»iese  characters  can 
be  made  up  of  any  remarks  the  user  wishes  to  input. 

CONTOUR  INTERVAL  —  Used  when  digitizing  bottom  contours.  The  user  is  asked 
to  input  this  value  if  "Bottom  Contour"  was  chosen  during  header 
selection.  The  current  elevation  can  be  incremented  or  decremented 
by  this  value.  The  user  can  change  this  value  by  entering 
"Auxiliary  Functions".- 


CORRECTED  DEPTH  —  An  echo  sounding  depth  value  that  has  been  adjusted 

according  to  the  salinity,  density,  and  temperature  of  the  water. 

COURSE  Tolerance  —  During  fathogram  processing,  the  maximum  acceptable 

difference  in  degrees  between  the  given  course  and  the  computed 
adjusted  course. 

DATA  BLOCK  --  A  64-word  block  used  to  store  feature  data.  In  table  data  files 
these  blocks  consist  of  X,  Y  or  X,Y,  depth  points.  In  geographic 
file  data  blocks,  the  data  is  stored  in  lat.  Ion  or  lat.  Ion,  depth 
values . 

DATA  FILE  --  (DF  "jobid")  —  A  table  file  comprised  of  feature  data  sets. 

These  sets  consist  of  a  feature  header  block  and  its  corresponding 
data  blocks.  Each  block  is  64  words  long.  In  the  data  blocks, 
data  is  stored  in  X,  Y  coordinates  and  X,  Y,  depth  coordinates. 

It  is  located  in  DP0. 

DATUM  SHIFT  CONSTANTS  -  X,  Y,  and  Z  offsets  of  the  ellipsoid  center  for  a 
particular  geographic  area. 

DIRECTORY  —  A  path  within  a  total  disk  organization  leading  to  a  specified 
set  of  programs.  BDRS  consists  of  a  master  directory,  DP0,  and 
three  other  directories  -  DBASE,  BATCH,  and  TABLE. 

DISCRETE  POINTS  —  A  single  digitized  point  with  no  sounding  value. 

EASTING  —  Used  when  registering  a  UTM  chart  for  digitization.  The  value 
can  be  found  on  the  chart. 

ELLIPSOID  (SPHEROID)  CODE  —  A  number  indicating  to  which  ellipsoid  model 
the  geographic  data  is  referenced. 

FATHOGRAM  FILE  (FF  "jobid")  —  A  fil'j  created  when  a  fathogram  is  digitized. 

It  contains  information  about  the  depth  scale  and  time  scale  of 
the  fathogram. 

FEATURE  —  A  group  of  related  digital  data. 

FEATURE  INDEX  BLOCK  —  A  64-word  block  containing  pointer,  window,  and  mask 
information  about  some  feature. 
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FOREGROUND  TERMINAL  FOR  BDRS  --  The  secondary  console  for  use  of  BDRS  functions. 
This  terminal  can  only  be  used  by  initiation  from  the  background. 

GEOGRAPHIC  BOUNDS  --  The  user  specified  geographic  area  beginning  with  the 
lower  left  lat/lon  and  preceding  in  a  clockwise  direction. 

GEOGRAPHIC  FILE  (GO  "jobid")  —  A  file  in  which  data  is  stored  in  lat/lon 

values.  The  BDRS  standard  geographic  file  is  comprised  of  records 
that  are  64  words  long.  Records  number  one  through  four  contain 
parameter  block  one  and  two,  registration  block,  and  comment  block. 

The  subsequent  records  are  comprised  of  feature  sets.  Each  set 
contains  a  geographic  header  followed  by  its  corresponding  data 
blocks.  It  is  located  in  DP0. 

GEO-SECTIONED  FILE  —  A  file  that  has  been  created  by  retrieving  data  from  the 
data  base  within  a  specified  geographic  area. 

HEADER  (FEATURE  HEADER)  —  A  64  word  block  found  at  the  beginning  of  a  feature 
data  set  containing  parameters  describing  the  specific  feature. 

HEADER  FILE  (HF  "jobid")  —  A  table  file  created  when  digitization  occurs. 

It  consists  of  headers  chosen  by  the  operator  from  the  Bathymetric 
Master  Library  of  headers  on  disk  for  inclusion  into  the  job's 
working  header  set  during  Header  Select  Mode.  It  is  located  in 
DP0. 

INDEX  FILE  (IF  "jobid")  —  A  multipurpose  table  file  containing  the  following 
64  word  blocks:  parameter  one  and  two,  registration,  comment,  and 
feature  index.  It  is  located  in  DP0. 

INPUT  FILENAME  —  In  any  BDRS  function,  the  name  of  an  existing  file  on  which 
some  operation  will  be  performed,  (one  to  eight  characters) . 

INTERMEDIATE  PLOT  FILE  —  A  disk  resident  plot  file  containing  the  correctly 

formatted  data  needed  by  the  "PLOTDR"  function  to  produce  a  Xynectic 
or  Calcomp  compatible  magnetic  tape  plot  file.  All  intermediate 
plot  files  are  stored  in  directory  Batch  and  are  named  "PLOTXX." 

The  "XX"  represents  the  2  character  extension  input  by  the  user 
at  the  time  the  intermediate  plot  file  is  created. 
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JOB  I.U.  —  A  one  to  eight  character  name  identifying  a  table  file.  This 
name  can  be  made  up  of  characters,  numbers,  or  both. 


LEFT  LONGITUDE  —  The  left  most  longitude  of  the  area  being  digitized. 

LOGICAL  DELETION  --  An  option  within  the  Data  Base  Batch  function.  This  allows 
a  user  to  mark  a  specific  document  or  a  specific  sheet  of  the  document 
for  deletion.  Once  the  document  is  marked,  it  can  be  physically 
deleted  using  Master  Mode  in  Data  Base.  If  marked  for  a  total  or  a 
partial  deletion,  the  document  cannot  be  retrieved  geographically 
or  by  the  document  number. 

LOGICAL  RETRIEVAL —  An  option  in  the  Data  Base  Batch  function.  This  option 

allows  a  user  to  retrieve  data  geographically  according  to  specified 
parameters.  Data  may  be  retrieved  by  the  shipname,  the  evaluation 
code  or  by  the  date. 

MAP  PROJECTION  —  A  representation  or  method  of  representing  all  or  part  of 
the  surface  of  a  sphere  or  spheroid,  such  as  the  earth,  upon  a 
plane  surface. 

MATHEWS  TABLE  AREA  —  An  area  of  the  world  numbered  1-52.  For  each  specific 
area,  Mathews  Table  contains  sounding  correction  values  based  on 
salinity,  water  density,  and  temperature. 

NORTHING  —  A  value  found  on  a  UTM  chart  that  is  used  during  the  registration 
process . 

OCTAL  DUMP  —  The  contents  of  the  records  in  a  file  given  in  octal  numbers. 

OPERATOR  ID  —  The  user's  assigned  ID  or  his/her  name.  It  indicates  the 
person  exercising  the  Data  Base  Batch  fucntions. 

OUTPUT  FILENAME  —  The  name  of  the  file  to  be  created  by  some  BDRS  function. 

(one  to  eight  characters) . 

PARAMETER  BLOCKS  —  64-word  blocks  used  to  record  and  store  the  status  and 
control  information  for  a  job. 

PLATFORM  NAME  —  A  one  to  twenty -seven  character  shipname. 


PLOT  KILL  EXTENSION  —  A  2  character  addition  to  an  intermediate  plot 

filename.  When  an  intermediate  plot  file  is  created,  its  file¬ 
name  is  "PLOTXX" ,  where  "XX"  is  the  plot  file  extension. 

QUADRANT  CODE  --  A  number  from  1-4  indicating  a  specific  quadrant  of  the 
earth's  surface.  (1  =  NE,  2  =  NW,  3  =  SW,  4  =  SE) . 

RECORDING  RESOLUTION  —  In  trace  data,  the  distance  in  mils  to  the  next 
point  that  will  be  recorded. 

REGISTRATION  —  Corresponding  a  latitude  and  longitude  value  with  table 

X  and  Y  coordinates.  Registration  takes  a  minimum  of  two  points 
and  a  maximum  of  eight. 

REGISTRATION  BLOCK  —  A  64  word  block  containing  the  X,  Y  registration 
points  and  their  corresponding  lat,  Ion  values. 

REQUESTOR  ID  —  The  assigned  ID  of  the  individual  desiring  specific  use  of 

the  data  base.  This  ID  has  to  be  valid  and  located  in  the  data  base 
or  the  request  will  be  rejected. 

RESIDUALS  —  The  distance  between  the  original  registration  points  and  the 
new  re-registered  points  in  mils. 

RIGHT  LONGITUDE  —  The  right  longitude  of  the  area  being  digitized. 

SEARCH  TOLERANCE  —  Used  to  locate  a  feature  during  Edit  Mode.  When  using 

trace  data  edit,  the  search  tolerance  is  used  in  joining  candidate 
features  to  edit  segments. 

SHEET  NUMBER  —  A  four  character  code  used  to  identify  a  specific  sheet  of 
a  document. 

SHIP'S  LOG  FILE  —  A  specially  formatted  file  containing  ship's  navigational 
log  data  (time,  course,  speed,  latitude,  longitude)  used  for 
fathogram  processing.  It  is  located  in  directory  Batch.  A  ship's 
log  file  must  be  created  for  every  fathogram  that  is  processed. 

SOUNDING  COMPARISON  PERCENTAGE  RANGE  —  In  BDRS  Depth  Adjustment  function,  the 
plus/minus  percentage  range  used  to  compare  a  sounding  to  the 
average  sounding  for  that  particular  geographic  area  stored  in 
the  data  base. 
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SOURCE  DESCRIPTION  RECORD  —  A  252  word  BDRS  record  identified  by  the  source 
ID.  This  record  contains  specific  information  concerning  the  data 
associated  with  it.  It  contains  such  things  as  the  document 
number,  shipname,  the  date,  and  other  specific  information  cm  the 
data. 

SOURCE  ID  —  A  twenty  character  code  that  identifies  the  source  description 
record.  This  code  must  be  exactly  twenty  characters. 

SPEED  TOLERANCE  —  During  fathogram  processing,  the  maximum  acceptable 

difference  in  knots  between  the  given  speed  and  the  computed  ad¬ 
justed  speed. 

STANDARD  PARALLEL  —  A  parallel  on  a  map  projection  along  which  the  scale 
is  as  stated. 

TABLE  FILE  —  A  file  in  which  data  is  stored  in  X,  Y  coordinates.  The  BDRS 
standard  table  file  consists  of  four  distinct  disk  resident  files, 
each  unique  to  the  job  name:  header  file,  index  file,  data  file, 
and  fathogram  file  (when  a  fathogram  is  digitized) .  It  is  located 
in  DP0. 

TO  DATE  —  The  date  associated  with  the  data  and  stored  in  the  source  des¬ 
cription  records.  Data  can  be  retrieved  from  the  data  base  using 
this  date. 

TOP  LATITUDE  —  The  top  Nbrthernmost  latitude  of  the  area  being  digitized. 

TRACE  DATA  —  A  series  of  digitized  points  that  form  a  continuous  line. 

UNCORRECTED  DEPTH  —  An  echo  sounding  depth  value  that  has  not  been  adjusted 
according  to  the  salinity,  density,  and  temperature  of  the  water. 

utm  zone  NUMBER  —  A  number  from  1  to  60  representing  a  specific  Universal 
Transverse  Mercator  Zone.  Beginning  at  the  180th  meridian,  6° 
columns  are  numbered  1  through  60  eastward. 

ZULU  TIME  —  Greenwich  mean  time,  (the  zone  time  at  the  Greenwich  (0°) 
meridian) . 
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APPENDIX  C 

BDRS  FILFS  AND  RECORD  FORMATS 


BDRS  DATA  BASE  DOCUMENT  DESCRIPTION  RECORD  (252  WORDS) 


#  OFFBATURES 


LOGICAL  DELETE  FLAG 


MO 


_ DA 

YR 


DATE  OF 
DELETION 

USER- ID  OF 
DELE  TOR 


•e  SOURCE  DISC.  RICOBB  -  212  WOB0I 


BDRS  GEOGRAPHIC  FILE  FORMAT 


The  BDRS  Standard  Geographic  File  Format  is  depicted  in  Figure  No.  A-l. 
It  is  comprised  of  64  word  records  of  which  record  number  one  thru  record 
number  four  contain  parameter  block  one,  parameter  block  two,  registration 
block  and  comment  block.  The  subsequent  records  are  comprised  of  feature 
sets.  Each  set  contains  a  BDRS  geographic  header  followed  by  geographic 
data  record (s) .  The  following  word  position,  field,  description  and  record 


layout 

define  each 

element  within  the  above 

mentioned  records. 

PARAMETER  BLOCK  #1 

WORD 

FIELD 

DESCRIPTION 

1 

GO 

Geo.  File  Flag  (ASCII  "GO") 

2 

DOCNUM 

Doc.  #  (10  ASCII)  - 

7  bits 

0-7 

FATHO 

1  if  Fathogram,  0  otherwise 

7  bits 

8-15 

UOM 

Units  of  Measure 

1  Meters. Meters 

2  Feet. Feet 

3  Fa thorns. Feet 

4  Fathoms. Fathoms 

B  bits 

0-7 

REGTYP 

0  if  Fathogram 

1  if  Correlation 

8  bits 

8-5 

RE  SOL 

Recording  Resolution 

9 

UNUSED 

10 

Base  Elevation/Depth 

Base  Contour 

11 

Interval 

Contour  Interval 

12-21 

SX 

Source  ID  (ASCII) 

S1-S2 

Country  Code 

S3 

Data  Type  ID 

S4-S14 

Platform  ID 

S15-S20 

Date 

22 

UNUSED 

23 

MON 

Month  of  Conversion  (ASCII) 

C-8 


WORD 

FIELD 

DESCRIPTION 

24 

DAY 

Day  of  Conversion  (ASCII) 

25 

YEAR 

Year  of  Conversion  (ASCII) 

26-29 

System  Converted  from  (ASCII) 

30-31 

Sheet  Number  (4  ASCII  Character) 

32-33 

NSD 

Total  #  of  Soundings  for  File* 

34-35 

NPT 

Total  #  of  Discrete  Points  for 

File* 

36-40 

ASCII  Filename 

Filename 

41-46 

UNUSED 

47-58 

Least  Squares  Coefficients 
(Deformation  Coefficients)  - 

47-48 

AA* 

49-50 

BB* 

51-52 

CC* 

53-54 

DD* 

55-56 

EE* 

57-58 

FF* 

59-64 

UNUSED 

‘NOTE  -  Single  Precision  Floating  Point 


C-9 


PARAMETER 

BLOCK  I  1 

PARAMETER 

BLOCK  §  2 

REGISTRATION  BLOCK 

COMMENT  BLOCK 

FEATURE  1 
HEADER 

BLOCK 

FEATURE  1 
DATA  BLOCK (S) 

IN  GEOCRAPHICS 

<* 

/ 

FEATURE  -  N 
HEADER  BLOCK 


FEATURE  -  N 
DATA  BLOCK (S) 


80RS  STANOARO  GEOGRAPHIC  FILE  FORMAT 


PARAMETER  BLOCK  #  2 


WORD 

FIELD 

1-4 

A 

5-8 

B 

0-12 

E 

13-16 

EP 

o 

CN. 

1 

r* 

CM 

21-24 

BL 

25-28 

UP 

29-32 

LP 

33-36 

CHL 

37-40 

RMS 

41-44 

TLAT 

45-48 

BLAT 

49-52 

TLQN 

53-56 

RLON 

57 

IQUAD 

58 

IPROJ 

59 

IZN 

60 

ISC 

**NOTE  -  Double  Precision  Floating 


DESCRIPTION 

Major  Axis  of  Earth  Model 
Ellipsoid** 

Minor  Axis** 

First  Eccentricity** 
Second  Eccentricity** 
Chart  Central  Meridian** 
Base  Latitude** 

Upper  Standard  Parallel** 
Lower  Standard  Parallel** 
Chart  Left  Longitude** 

Map  Scale** 

Top  Latitude** 

Bottom  Latitude** 

Left  Longitude** 

Right  Longitude** 

Quadrant 

1  -  NE 

2  -  NW 

3  -  SW 

4  -  SE 

Projection  Type 

1  -  UTM  Grid 

2  -  Mercator 

3  -  Lambert 

4  -  Polyconic 

5  -  Miller 

UTM  Zone  Number 
Speroid  Code 

1  -  CLARK  1866 

2  -  CLARK  1880 

3  -  CLARK  1858 

Point 
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WORD 


FIELD 


DESCRIPTION 


61-64 


UNUSED 


4  -  BESSEL 

5  -  HOUGH 

6  -  WGS  72 

7  -  WGS  80 

8  -  INTERNATIONAL 

9  -  KRASSOUSKY 
10  -  EVEREST 

1J  -  AUSTRALIAN 

12  -  FISCHER 

13  -  AIRY 


C-13 


REGISTRATION  BLOCK 


WORD 

FIELD 

DESCRIPTION 

1 

NRP 

Number  of  registrates  points  use  for 

registration  max  of  ten 

2-4 

UNUSED 

5 

RXl 

X(l)  Value  used  in  Registration 

Y  ( 1 ) 

X  (2) 

• 

Y  (2) 

23 

RXlO 

X(10)  Value  used  in  Registration 

24 

RY10 

Y ( 10)  "  "  "  " 

25-26 

LAT1* 

LAT(l)  Latitude  used  in  Registration- 

units  .01"  of  arc 

27-28 

LONGl* 

LONG(l)  Longitude  used  in  Registration 

- 

units  .01"  of  arc 

61-62 

LAT10* 

LAT(10)  Latitude  used  in  Registration 

units  .01"  of  arc 

63-64 

LONGIO* 

LONG(IO)  Longitude  used  in  Registratior 

units  .01"  of  arc 

C-15 


COMMENT  BLOCK 


WORD 

FIELD 

DESCRIPTION 

1 

Comment  block  contains  user  generated 

comments .  Note :  A  zero  byte  denotes 

a  carriage  return,  the  second  zero 

byte  denotes  end  of  comment  for  recor 

64 
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feature  header  record 


WoHD 

FIELD 

DESCRIPTION 

1 

HDRFLG(-l) 

Header  Block  Flay 

2  bits  0-7 

CC 

Binary  Class  Code 

bits  8-15 

TT 

Binary  Type  Code 

3  bits  0-7 

SS 

Binary  Subtype  Code 

3  bits  8-15 

to 

8 

DX 

Descriptor  Codes  in  ASCII 

9 

NOB 

Number  of  Data  Blocks  in  feature 

10-11 

L ATM IN 

Geographic  Minimum  of  Feature  Latitude* 

12-13 

LONMIN 

Minimum  of  Longitude* 

14-15 

LATMX 

Maximum  of  Latitude* 

16-17 

LONMX 

Maximum  of  Longitude* 

18-19 

FSTLAT 

First  Latitude  of  Feature* 

20-21 

FSTLON 

First  Longitude  of  Feature* 

22-23 

LSTLAT 

Last  Latitude  of  Features* 

24-25 

LSTLON 

Last  Longitude  of  Feature* 

26 

NDB 

Number  of  Discrete  Points  Within 

Feature  Data  Blocks 

27 

NSD 

Number  of  Soundings  in  Ensuing  Data 

Blocks 

28-  1 

SX 

SOURCE  ID  (ASCII) 

S1-S2 

Country  Code  ID 

S3 

Datatype  ID 

S4-S14 

Platform  ID 

S15-20 

DATE 

38 

Base/e le/depth 

Base  Contour 

39 

Interval 

Contour  Interval 

40 

DS 

Depth  Scale 

41 

TS 

Time  Scale 

i 


335- 


WORD 

FIELD 

DESCRIPTION 

42 

RE SOL. 

Resolution  in  Mils 

43-47 

DN 

Document  Number  (ASCII) 

48-49 

DHN 

Sheet  Number  (ASCII) 

50-51 

MIND 

Minimum  Depth* 

52-53 

MAXD 

Maximum  Depth* 

54  Bits  0-7 

UNCOR 

Uncorrected/corrected  soundings 
(O-Uncorrected ,  1-corrected) 

54  Bits  8-15 

UOM 

Unit  of  Measure 

1  -  Meters. Meters 

2  -  Feet. Feet 

3  -  Fathoms. Feet 

4  -  Fathoms . Fathoms 

55-64  Free  Text 


‘NOTE  -  Single  Precision  Floating  Point 
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HDRFL  (-1) 


15  WORD 
"1  33 


CC 

TT 

ss 

D1 

D2 

D3 

D4 

D5 

D6 

D7 

D8 

D9 

DIO 

UNUSED 

BASE  ELEVATION/DEPTH 


INTERVAL 


DS  DEPTH  SCALE 


TS  TIME  SCALE 


RESOL  (RESOLUTION) 


DN  (DOCUMENT) 


NUMBER  10  ASCII 


CHAR 


SHEET  NUMBER  4  ASCII 


CHAR 


MINIMUM  DEPTH 


MAXIMUM  DEPTH 


UNCOR 


FREE  TEXT  AREA 


(20  ASCII  CHAR) 


* 


GEOGRAPHIC  DATA  RECORD 

The  BDRS  standard  geographic  data  block  is  constructed  as  follows.  A 
minus  two  in  the  first  word  indicates  the  beginning  of  a  geographic  data 
block.  The  second  word  contains  the  specific  block  number,  e.g.,  a  counter. 
The  third  word  is  a  data  type/number  of  points  in  data  field  code. 

Bits  0-1  are  the  data  type  code 
0-0  increment 
0-1  absolute 

1-0  incremental,  bits  0-7  latitude,  8-15  longitude 

Bits  2-15  give  the  number  of  points  in  the  data  type  field  that  follows. 

A  value  other  than  zero  (0)  in  word  27  of  the  header  block  indicates 
that  the  data  block  contains  depth  values.  The  data  will  be  constructed 
similar  to  one  of  the  configurations  in  Figure  No.  7.  If  a  zero  (0)  is 
contained  in  word  27  of  the  header  block,  no  depth  values  are  contained  in 
the  data  block.  It  will  be  constructed  similar  to  one  of  the  data  blocks 
in  Figure  No.  8.  A  change  of  data  type  is  indicated  by  encountering  a  new 
two  bit  data  type  code,  followed  by  the  number  of  points  in  the  new  data 
type  field. 

The  00  incremental  value  consists  of  two  16-bit  Data  General  integer 
words,  one  word  for  latitude  and  one  word  for  longitude.  The  01  absolute 
values  consist  of  four  16  bit  Data  General  words  (two  floating  point  values) , 
two  words  for  latitude  and  two  words  for  longitude.  Note:  Each  Data  General 
floating  point  value  consists  of  two  16  bit  Data  General  words  (Reference 
Programmer's  Reference  Manual  ECLIPSE  COMPUTER  015-0000-24-00) .  The  10 
incremental  values  consist  of  one  integer  word  containing  a  latitude  and 
longitude  (2  bytes) .  Each  byte  is  a  signed  magnitude  of  a  value  in  the 
range:  l£MAGNITUDE£l27  (with  a  least  count  of  .91") .  The  first  bit  of  each 
byte  is  the  sign  bit  and  the  remaining  seven  bits  contain  a  value  between 
zero  and  one  hundred  and  twenty  seven.  Figure  No.  9  depicts  an  example  of 
a  data  block  with  soundings. 


C-22 


WORD 

1 

DATA  BLOCK  FLAG 

2 

DATA  BLOCK  NUMBER 

INCREMENTAL  A 

3 

n  n 

NUMBER  OF  POINTS 

<1 

LATITUDE  (.01") 

S 

LONGITUDE  (.01")  _ 

b 

DEPTH 

7 

FLOATING  POINT 

< 

r _ 

1 

_ 3 

WORD 

64 

ABSOLUTE 


WORD  t 

DATA  BLOCK  FLAG  -2 

2 

3 

4 

5 

6 

7 

8 

9 

#> 

WORD  64 

WORD  1 

2 

3 

4 

5 

6 

Word  64 

DATA  BLOCK  NUMBER 

0  1  NUMBER  OF  POINTS 

LATITUDE 

FLOATING  POINT 

LONGITUDE 

FLOATING  POINT 

DEPTH 

FLOATING  POINT 

DATA  BLOCK  FLAG  -2 

DATA  BLOCK  NUMBER 

1  0  |  NUMBER  OF  POINTS 

S  1  LATITUDE  (MAG)  |  S  I  LONGITUDE  (MAG) 

DEPTH 

FLOATING  POINT 

BDRS  GEOGRAPHIC  DATA  BLOCKS  WITH  SOUNDINGS 
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WORD  1 


DATA  BLOCK  FLAG 


INCREMENTAL  A 


DATA  BLOCK  NUMBER 
NUMBER  OF  POINTS . 
LATITUDE  ( .01'*) 
LONGITUDE  (.01") 


WORD  04 


augolijti-: 


WORD  L 


3  0  1 


DATA  BLOCK  FLAG 
DATA  BLOCK  NUMBER 
NUMBER  OP  POINTS 
LATITUDE 
FLOATING  POINT 
LONGITUDE 
FLOATING  POINT 


WORD  64 


WORD  1 


WORD  64 


DATA  BLOCK  FLAG  -2 

_ DATA  BLOCK  NUMBER _ 

1  NUMBER  OF  POINTS 

LATITUDE  (MAG)  1  S  1  LONGITUDE  (MAG 


BDRS  OATA  BLOCKS  WITHOUT  SOUNDINGS 


C-2 


ip 


'S£SGSi3E3gav 


1 

— 

-2 

13 

LAT 

LONG 

i 

14 

DEPTH 

FLOATING 

1 

1 

PO  T  NT 

4 

1 

LATITUDE  FLOATING 

36 

5 

POINT  (.01) 

37 

b 

LONGITUDE  FLOATING 

JF 

7 

POINT  (.01) 

39 

a 

DEPTH 

40 

y 

FLOATING  POINT 

41 

10 

00 

3 

42 

11 

LATITUDE 

43 

44 

12 

LONGITUDE 

13 

DEPTH  FLOATING 

45 

14 

POINT 

46 

15 

LATITUDE 

47 

16 

LONGITUDE 

48 

17 

DEPTH  FLOATING 

49 

18 

POINT 

50 

19 

LATITUDE 

51 

20 

LONGITUDE 

52 

21 

DEPTH  FLOATING 

53 

22 

POINT 

54 

23 

4 

55 

24 

LAT 

LONG 

56 

25 

DEPTH  FLOATING 

57 

26 

POINT 

58 

27 

LAT 

LONG 

59 

28 

DEPTH  FLOATING 

60 

29 

POINT 

61 

30 

LAT 

LONG 

62 

31 

DEPTH  FLOATING 

b  3 

32 

POINT 

64 
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bPKS  DIGITIZING  TABLE  AND  FILES  FORMAT 


The  BDRS  Standard  Table  Files  consist  of  four  distinct  disk  resident 
files,  each  unique  to  the  job  name:  Header  File,  Index  File,  Data  File,  and 
F athoqram  File  (when  fathogram  is  digitized) .  Each  file  and  the  record 
content  will  be  discussed  in  the  proceeding  paragraphs. 

Header  File 

The  Header  File  (Filename  HF  job  I.D.)  depicted  in  Figure  No.  A-10  con¬ 
sists  of  headers  chosen  by  the  operator  from  the  Bathymetric  Master  Library 
of  headers  on  disk  for  inclusion  into  the  job's  working  header  set  during 
Header  Select  Mode.  (The  Bathymetric  Master  Library  file's  names  for  Station 
#1  and  Station  #2  are  "BDRS . HF"  and  "VBDRS.HF"  respectively).  In  addition, 
each  time  a  new  permanent  header  is  created  in  Master  Mode,  it  is  appended 
to  the  Header  File.  Each  header  entry  is  stored  as  a  string  of  ASCII  char¬ 
acters  expanded  out  to  62  characters  with  blanks  to  make  the  Header  Entry  31 
integer  wods  long  (Figure  No.  A- 11) . 

The  following  is  an  example  of  header: 

13010200000000000000000000  ABOVE  MEAN  HIGH  WATER 
where  the  twenty  six  digit  code  represents  an  LIS  compatible  header  code,  and 
the  remaining  characters  are  the  textual  header  description.  The  Header  File 
is  organized  into  "pages"  of  15  headers  each  to  facilitate  their  display  on 
the  CRT  terminal.  A  Header  Entry  Format  is  as  follows: 


WORD 

FIELD 

DESCRIPTION 

1 

CC 

LIS- compatible 

Class  Code 

(2  ASCII  characters) 

2 

TT 

LIS-compatible 

Type  Code 

(2  ASCII  characters) 

3 

SS 

LIS-compatible 

Subtype  Code  (2  ASCII  characters) 

4-13 

DX 

LIS-compatible 

Descriptor 

Codes  (20  ASCII  char- 

14-31 

Index  File 

CX 

Free  Text  Field  (36  ASCII 

.  ^  .  acters) 

characters) 

The  Index  File,  (filename  IF  job  I.D.)  depicted  in  Figure  No.  A-12  is  a  multi¬ 
purpose  file.  It  contains  parameters,  registration,  commentary,  and  index  blocks 


64  words  in  length.  The  parameter  blocks  are  used  to  record  the  status  and 
control  information  for  a  job.  The  comment  block  is  used  to  store  ASCII  char¬ 
acters  input  by  the  user  in  the  Master  Mode  auxiliary  functions.  These  char¬ 
acters  can  be  made  up  of  any  remarks  the  user  wishes  to  input.  The  index 
block  contains  pointer,  window  and  mask  information  about  some  feature. 


Parameter  Block  #1 

Parameter  block  number  one  is  depicted  in  Figure  No.  A-13  and  its 
description  is  as  follows: 


WORD  FIELD 

1-6  INAME 

7  IFUOM 


8  DKRES 

9  LAS THE 

10  LASTBL 


11  ICHDR 


12  ELBASE 

13  CONINT 

14  UNUSED 

15  TPTS 


DESCRIPTION 

ASCII  "IF"  followed  by  eight  ASCII 
character  job  I.D. 

Bits  0-7  Fathogram  indicator,  if  bit  0-7 
equal  one  fathogram  file 
Bits  8-15  Units  of  Measure 

1  -  Meters. Meters 

2  -  Feet. Feet 

3  -  Fathoms . Feet 

4  -  Fathoms . Fathoms 

Digitizing  table  recording  resolution  in  mi 

Last  header  block  pointer  (random  pointer 
into  file  DF  job  I.D.) 

Last  data  block  pointer  (random  record 
pointer  into  file  DF  job  I.D.) 

Current  header  block  pointer  (random 

record  pointer  into  file  DF  job  I.D.) 

Base  elevation/depth 

Base  elevation/depth  interval 


C-27 


Total  number  of  discrete  points  in 
file  (DF  job  I.D.) 


q-28 


•PfPSS iff 


0 

8 

16 

1 

C 

C 

2 

T 

T 

3 

S 

S 

4 

01 

02 

5 

D3 

D4 

6 

D5 

D6 

7 

07 

D8 

U 

D9 

DIO 

y 

Dll 

D12 

10 

013 

D14 

11 

015 

Dl6 

12 

D17 

DIB 

i  J 

D19 

D20 

14 

Cl 

C2 

15 

C3 

C4 

16 

CS 

C6 

17 

C7 

C8 

18 

C9 

CIO 

19 

Cll 

C12 

20 

C13 

C14 

21 

C15 

C16 

22 

Cl  7 

CIS 

23 

Cl  9 

C20 

24 

C21 

C22 

25 

C23 

C24 

26 

C25 

C26 

27 

C27 

C28 

28 

C29 

C30 

29 

C31 

C32 

30 

C33 

C34 

31 

■ 

C35 

C36 

WORKING  HEADER  BLOCK  FORMAT 
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I'AlvAMKTKK  BLOCK  #1 


I AN  AMI  .'TEI<  Hl.oCK  #2 


KLOl STRATI ON  BLOCK 


COMMENT  BLOCK 


FEATURE  INDEX  BLOCK 


FEATURE  INDEX  BLOCK 


BORS  FEATURE  INDEX  FILE 
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WORD 

FIELD 

DESCRIPTION 

16 

TSDS 

Total  number  of  soundings  in  file  (DF  job  I.D.) 

17 

TFTS 

Total  number  of  features  in  file  (DF  job  I.D.) 

18 

UNUSED 

19 

UNUSED 

20 

LHLINE 

Pointer  to  the  current  page  of  header  to  indicate 

the  present  header  selected  (HF  job  I.D.) 

21-30 

ISID 

Source  I.D.  (20  ASCII  characters) 

31 

FIBP 

Block  index  pointer  (random  record  pointer 

into  file  IF  Job  I.D.) 

32 

FIWP 

Next  unused  word  pointer  into  block  FIBP 

33 

I  DSC 

Display  Scale 

34 

STRMOD 

35 

NEW 

New  job  flag  (NEW  =  1) 

36 

CORECT 

Uncorrected/corrected  depth  values 

(O^uncorrected,  l=corrected) 

37 

FTHBLP 

Random  pointer  to  last  fathogram  parameter  block 

written  to  file  FF  job  I.D. 

38-39 

AA 

Least  square  coefficients  used  to  correct 

40-41 

BB 

input  X , Y  values  back  to  day  one 

42-43 

CC 

registration  form. 

44-45 

DD 

46-47 

FF 

48-49 

GG 

50-55 

UNUSED 

56-60 

DOCNO 

Document  number  (10  ASCII  characters) 

61-62 

SHEET 

Sheet  number  (4  ASCII  numeric  characters) 

63-64 

UNUSED 

C- 31 


BLK  INDEX  PTR 
WORD  INDEX  PTR 


NOT  USED 


PARAMETER  BLOCK  #2 

WORD 

FIELD 

DESCRIPTION 

1-4 

A 

Major  Axis  of  Earth  Model  Ellipsoid 

5-8 

B 

Minor  Axis** 

9-12 

E 

First  Eccentricity** 

13-16 

EP 

Second  Eccentricity** 

17-20 

CM 

Chart  Central  Meridian** 

21-24 

BL 

Base  Latitude** 

25-28 

UP 

Upper  Standard  Parallel** 

29-32 

LP 

Lower  Standard  Parallel* 

33-36 

CHL 

Chart  Left  Longitude** 

37-40 

RMS 

Map  Scale** 

41-44 

TLAT 

Top  Latitude** 

45-48 

BLAT 

Bottom  Latitude** 

49-52 

TLON 

Left  Longitude** 

53-56 

RLON 

Right  Longitude** 

57 

IQUAD 

Quadrant 

1  =  NE 

2  =  NW 

3  =  SW 

4  =  SE 

58  IPROJ  Projection  Type 

1  =  UTM  Grid 

2  =  Mercator 

3  =  Lambert 

4  =  Polyconic 

5  =  Miller 

59  IZN  UTM  Zone  Number 

60  ISC  1  -  CLARK  1866 

2  -  CLARK  1858 

3  -  CLARK  1858 

4  -  BESSEL 


5  -  HOUGH 

6  -  WGS  72 


FIELD 


DESCRIPTION 


UNUSED 


1  -  WGS  80 

8  -  INTERNATIONAL 

9  -  KRASSOUSKY 

10  -  EVEREST 

11  -  AUSTRALIAN 

12  -  FISCHER 

13  -  AIRY 


i 

j 

i 


* 


REGISTRATION  BLOCK 


WORD 

FIELD 

DESCRIPTION 

1 

NRP 

Number  of  registrates  points  used  for 

registration  (max  of  ten) 

2-4 

UNUSED 

5 

RX1 

X ( 1 >  Value  used  in  Registration 

6 

RY1 

Y(l)  Value  used  in  Registration 

7 

RX2 

X(2)  Value  used  in  Registration 

8 

RY2 

Y(2)  Value  used  in  Registration 

23 

RX10 

X(10)  Value  used  in  Registration 

24 

RY10 

Y(10)  Value  used  in  Registration 

25-26 

LAT1  * 

LAT(l)  Latitude  used  in  Registration-units 

.01”  of  arc 

27-28 

LONGl* 

LONG ( 1 )  Longitude  used  in  Registration-units 

• 

.01"  of  arc 

61-62 

LAT10* 

LAT(IO)  Latitude  used  in  Registration-units 

.01"  of  arc 

63-64 

LONGl 0* 

LONG(IO)  Longitude  used  in  Registration-units 

.01"  of  arc 

*Data  General  Single  Precision  Floating  Point. 


DESCRIPTION 


Comment  block  contains  user  generated 
comments.  Note:  A  zero  byte  denotes  a 
carriage  return,  the  second  zero 
byte  denotes  end  of  comment  for  record 


FEATURE  INDEX  BLOCK 

The  Feature  Index  Block  format  is  shown  in  Figure  No.  A-17.  Each  index 
record  contains  a  total  of  8  indices  per  64  word  block.  (Figure  No.  A-18) . 
The  elements  within  the  index  are  as  follows: 


WORD 

1 

2 


3 

m 


5 

6 

7 

8 


FIELD 

FEATURE 

POINTER 

MINX 


DESCRIPTION 

The  pointer  to  the  block  where  the 
header  for  the  feature  begins. 

The  smallest  X-value  in  which  the 
feature  is  contained. 


MINY 

MAX  X 

MAX  Y 

CC 

TT 

SS 


The  smallest  Y-value  in  which  the  feature  is 
contained. 

The  largest  X-value  in  which  the 
feature  is  contained. 

The  largest  Y-value  in  which  the 
feature  is  contained. 

LIS-compatible  Type  code  (2  ASCII 
characters) 

LIS-compatible  Type  code  (2  ASCII 
characters) 

LIS-compatible  Subtype  code  (2  ASCII 
characters) 


NOTE:  Word  31  of  parameter  block  number  one  is  the  random  index 
pointer  to  the  feature  index  block  in  use.  Word  32  of 
parameter  block  number  one  is  the  word  pointer  of  the  next 
unused  8  word  set  for  storing  the  next  feature's  index. 
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<F 


BDRS  Table  Coordinate  Data  File 

The  BDRS  Table  Coordinate  Data  File  is  depicted  in  Figure  No.  A-19 
(file  name  DF  job  I.D.).  It  is  comprised  of  feature  data  sets.  Bach  set 
contains  a  feature  header  block  followed  by  N  data  blocks.  Each  block 
is  64  words  long. 

Feature  Header  Block 

The  Feature  Header  Block  (64  word  record)  contains  feature  parameter 
characteristics  as  shown  in  Figure  No.  A-20.  These  parameters  are  as 
follows: 


WORD 

FIELD 

DESCRIPTION 

1 

HID 

Header  identification.  This  value  is 

always  -1. 

2 

CC 

LIS- compatible  Class  Code  in  binary. 

2 

TT 

LIS-compatible  Type  code  in  binary 

3 

SS 

LlS-conqpatible  Subtype  code  in  binary 

3-8 

Dx 

LIS-compatible  code  in  binary 

8 

FATHO 

Fathogram  flag  code  as  follows: 

1  =  Start  selection  of  fathogram 

2  =  Continuation  of  long  fathogram 

where  the  Y-range  (depth)  has  not 
changed . 

3  =  Continuation  of  long  fathogram  where 

the  Y-range  (depth)  has  changed. 


9 

DEPTH/ELEV 

The  depth  or  elevation  value 

tours  data  which  follows. 

for  the  con- 

10 

INTERVAL 

Contour  interval. 

11 

SKIP  COUNT 

Used  to  denote  the  number  of 

data  blocks 

to  skip  if  this  feature  is  deleted.  It 
is  always  0  otherwise. 
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WORD 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 


23 


24-33 


34 


35 


36 

37 

38 

39 

40-57 


58-62 

63-64 


FIELD 

MINX 

MINY 

MAXX 

MAXY 

FIRST  X 

FIRST  Y 

LAST  X 

LAST  Y 

MIN  D 

MAX  D 

NDPTS 

N SOUND 

Sx 


DESCRIPTION 

The  feature  window  bounding  rectangle. 


The  first  coordinate  point  of  the  feature 


The  last  coordinate  point  of  the  feature 


Minimum  depth  value  for  sounding 

Maximum  depth  value  for  sounding 

Number  of  discrete  points  within  the 
data  blocks,  otherwise  0. 

Number  of  soundings  within  the  data  blocks, 
otherwise  0. 

Source  identification  for  this  feature 
(20  ASCII  char) 


BLOCK  INDEX  Points  to  the  block  within  the  index 

PTR 

file  which  has  the  index  for  this  feature 
(For  future  use) 


WORD  INDEX  PTR  Points  to  the  word  within  the  above  block 
(For  future  use) 


DEPTH  ORIGIN 
DEPTH  SCALE 
TIME  SCALE 
RESOLUTION 


Initial  depth  on  fathogram  D-Axis 
Increments  on  fathogram  D-Axis 
Increment  on  Fathogram  T-Axis 
Recording  resolutions  for  this  feature. 


Cx 


DOCNO 


Free  text  field  (96  ASCII  characters). 
This  is  derived  from  the  chosen  header 
in  Master  Mode. 

Document  number  (10  ASCII  Characters) 

Sheet  number  (4  ASCII  characters) 
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SHEET 


'■yj.  l>  -  ■*&&■*&*<***;■>■ 


HID  (-1) 


CC 

TT 

ss 

Dl 

D2 

D3 

D4 

D5 

D6 

D7 

D8 

D9 

D10 

FATHO 

DEPTH /E LEV 


INTERNAL 


SKIP 


MIN  X 


MIN  Y 


MAX  X 


MAX  Y 


FIRST  X  . 


FIRST  Y 


LAST  X 


LAST  Y 

MIN  D _ 

MAX  D _ 

NDPTS _ 

NSOUND 
__  |  - 


15  WORD 

~l  33 


S19 


BLOCK  INDEX  PTR 


WORD  INDEX  PTR 


DEPTH  ORIGIN 


DEPTH  SCALE 


TIME  SCALE 


RESOLUTION 


Data  Block 


The  Data  Block  is  used  to  store  the  digitized  feature  data.  Several 
data-word  types  are  used  as  shown  in  Figure  No.  A-21. 

NULL  VECTOR  -  used  to  denote  "no  data"  within  the  word. 

SHORT  VECTOR  -  A  3-bit  value  used  when  the  distance  from  the  current 
data  point  to  the  previous  point  is  equal  to  the 
resolution  increment.  Each  vector  is  assigned  a  value 
from  0-7  depending  on  the  new  points  direction  relative 
to  the  previours  point;  i.e.. 


tt 


Short  vectors  are  identified  by  0  in  the  high  bit  of 
the  word,  and  a  short  vector  count  (1  to  4)  in  the  word, 
contained  in  the  next  three  bits. 

LONG  VECTOR  -  Data  word  type  used  when  the  change  between  the  current 

and  previous  points  digitized  is  greater  than  1  resolution 
element  and  less  than  32  mils  on  either  axis.  Long  vectors 
are  identifiable  by  0  in  the  high  order  bit  of  the  data 
word,  and  5  in  the  next  three  bits. 

END  OF  DATA  -  A  word  containing  a  -2,  to  indicate  that  the  trace  feature 
string  has  terminated. 

DISCRETE  ABSOLUTE  POINT  -  used  in  discrete  point  mode.  Each  word  contains 
an  unsigned  16  bit  integer  word  for  X  and  V . 
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10.11  12  .13  14  15 


2  3 

4  5  6 

7  8  9 

— L.  -X- 

10  11  12 

13  14  15 

Ll 

0 

V' 

0 

0 

0 

} 

UL 

1 

VI 

0 

0 

0 

["'I  ' 

2 

VI 

V2 

0 

0 

gl: 

3 

VI 

V2 

V3 

0 

wm 

4 

VI 

V2 

V3 

V4 

J 

3} 


a 

5 

AX 

AY 

ABSOLUTE  X 
ABSOLUTE  Y 


► 

. 1 


_ -3 

ABSOLUTE  X 
ABSOLUTE  Y 


ABSOLUTE  X 
ABSOLUTE  Y 


DEPTH 


OATA  HOCK  FORMATS 


NIJU, 


SHORT 

VECTORS 


LONG  VECTORS 

END  OF  DATA  FOR 
TRACED  DATA 

DISCRETE 
ABSOLUTE  POINT 


EMBEDDED 

ABSOLUTE 

POINT 


ABSOLUTE 
POINT  6  DEPTH 


C- 


F/e  8/1 0 


AM091  942  SYNECTICS  CORP  ROME  N  Y 
”  nATHYMETRlC  OATA  REDUCTION  SYSTEM. (U) 

AU6  80  D  T  ALVAREZ#  j  R  TERENZETTE  f30602-76-C-0*12 

gi  ^CLASSIFIED  rU-0756-A  RADC-TR-80-27J  NL 


EMBEDDED  ABSOLUTE  POINT  -  used  in  trace  mode  when  the  change  betwei 
current  and  previous  point  is  32  mils  or  greater.  Ea< 
X, Y  point  is  tagged  with  a  -3  in  the  first  word. 

ABSOLUTE  POINT  &  DEPTH  -  used  in  D-entry  mode  to  denote  a  sounding 
The  first  two  words  are  the  X,Y  coordinate  (unsigned 
16-bit  integers)  and  the  third  word  represents  the  de 
value  as  a  32-bit  floating  point  number. 


MISSION 

of 


Center 


KADC  plan*  and  execute*  research,  development,  teat  and 
Wetted  acquisition  programs  In  support  oi  Comand ,  Contact 
Conmoucatcon*  and  Intelligence  (C*l)  activities.  Technical 
and  enyAncering  support  within  area*  oi  technical  competence 

lift  Alt  1  if  AM  ’  dh  MM3  .  i  .ft-  ... 


^  provided  to  ESP  Program  OUicu  (WaJ  and  other  E 
element*.  The  pfUncip.il  technical  mission  area*  one 
communication* ,  e£€c#u>magnetcc  guidance  and  contact, 
vei?a*:*  °i  mund  and  aerospace  object*,  inteULLges 


Collection  hut 

Aonoepkefua  propagation,  *otid  itate  sciences,  micAomm 
phif*4c*  and  electronic,  reliability,  maintainability  and 
compatibility. 


